On 11 July 2013 14:33, Steve Hay <steve....@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-unsubscr...@perl.apache.org For additional commands, e-mail: dev-h...@perl.apache.org
