perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Hay" <Steve....@verosoftware.com>
Subject RE: [httpd24 branch] merge with trunk?
Date Thu, 11 Jul 2013 13:33:56 GMT
Jan Kaluža wrote on 2013-07-11:
> On 07/11/2013 11:06 AM, Jan Kaluža wrote:
>>> So the problem here is that modperl_error.c is included in
>>> libaprext.lib, but it references the symbol "perl_module", which is
>>> defined in mod_perl.c, but that isn't included in libaprext.lib, so
>>> the symbol is unresolved when linking APR/Brigade.dll (and presumably
>>> any other APR/*.dll which links against libaprext.lib).
>>> 
>>> Simply throwing mod_perl.c into libaprext.lib too doesn't work
>>> because it references many, many other symbols which are also not
> included.
>> 
>>> So I think we need to move the definition of "perl_module" to some
>>> other file which either already is or else can be included in
>>> libaprext.lib, but I'm not sure where would be best right now.
>>> 
>> 
>> I think moving it to different file is not possible. perl_module
>> struct contains pointers to methods which later call another methods
>> which really need all those symbols. So to define perl_module, you
>> basically need all that stuff included in mod_perl.h.
>> 
>> I think what you could do is to create dummy .c file and just add dummy
>> perl_module definition there. No source code mentioned above (in
>> libaprext.lib) actually needs perl_module, so it should be OK to do
>> that. You wouldn't be able to use perl_module properly from external
>> library anyway if I'm right.
>> 
>> It's not ideal way, but I'm not sure I see better solution. I've
>> done that in ModPerl::Const:
>> 
>> http://jkaluza.fedorapeople.org/mod_perl/0023-Define-perl_module-in- Co
>> nst.xs.patch
> 
> When thinking about it, it's really strange we have problems with
> perl_module in httpd24 branch, because that part of code didn't change
> at all in httpd24 branch.
> 
> In trunk, the perl_module in mod_perl.h is declared as extern too and
> the files used to link libaprext.lib are also the same. Maybe there
> are different compler/linker flags in use when building with 2.4
> causing this behaviour?
> 
> I think that could be worth checking too.
> 

The problem arises from code in modperl_apache_compat.h which applies only to httpd-2.4 builds,
but which is already committed to trunk:

#if AP_SERVER_MAJORVERSION_NUMBER>2 || \
    (AP_SERVER_MAJORVERSION_NUMBER == 2 && AP_SERVER_MINORVERSION_NUMBER>=3)

/* 2.4 API */
...
#define mp_module_index_ perl_module.module_index,

#else
/* 2.2 API */
...
#define mp_module_index_

#endif /* 2.4 vs. 2.2 API */

Unless you can think of anything that we can change/move in that code then I'll pursue your
idea of a dummy .c file with a dummy definition of perl_module.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Mime
View raw message