perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <steve.m....@googlemail.com>
Subject Re: [httpd24 branch] merge with trunk?
Date Thu, 11 Jul 2013 23:29:13 GMT
On 11 July 2013 14:33, Steve Hay <Steve.Hay@verosoftware.com> wrote:
>
> 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).
> >>>
[...]
> >> 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.


That works a treat, so I've now done that in r1502392.

The problem of how to specify the path of aprutil-1 in
xs/APR/APR/Makefile.PL remains, but with the fix above the build now
proceeds to the next problem: Apache2/Provider.dll fails to link, with
an unresolved external symbol, ap_register_provider.

That symbol is exported from libhttpd.dll so I'm not sure right now
why the link fails because we *do* already link against libhttpd.lib
(and it has found it, along with libapr-1.lib and libaprutil-1.lib,
this time).

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


Mime
View raw message