Jan Kaluža wrote on 2013-07-11: > On 07/11/2013 01:17 AM, Steve Hay wrote: >> The first problem was "Warning (mostly harmless): No library found for >> -laprutil-1" appearing from Makefile.PL between ModPerl::WrapXS and APR >> (presumably it applies to the latter), which I've ignored for now but >> will probably come back to bite me later. No other such issues are >> reported, and all the libraries (apr-1.lib, aprutil-1.lib, >> libapr-1.lib, libapriconv-1.lib, libaprutil-1.lib, libhttpd.lib, >> mod_dav.lib and xml.lib) are together in C:\Apache24\lib, so I'm not >> sure what the problem is there yet. > > After thinking about that for a bit and checking all my patches I've > found out there's the same problem on Linux. I have overcame that with > quite hardcoded way last year when trying to get it work: > > http://jkaluza.fedorapeople.org/mod_perl/0020-Link-APR.so-against- > libaprutil-1.patch > > Something like that is probably needed on Windows too. Proper way > would be to fix Apache2::Build to include this library, but I was not > able to achieve that last year if I remember well. >
I see that patch is in the httpd24 branch so it is already being done on Windows just like any other OS, but the problem is that the path to the library in question isn't known. In my build $libs is -LD:\temp\mp2\MODPER~1\blib\arch\auto\LIBAPR~1 -laprext -laprutil-1 and libaprutil-l.lib is in D:\temp\mp2\apache\lib. If I manually add -LD:\temp\mp2\apache\lib into $libs then it builds fine but I'm struggling to automate that at the moment. The httpd lib path that I need is seemingly available from Apache2::BuildConfig: 'MODPERL_AP_LIBDIR' => 'D:\\temp\\mp2\\apache\\lib' but none of the MODPERL_* keys exist in the $build in xs/APR/APR/Makefile.PL; they are presumably generated later. >> Next, modperl_apache_compat.c complains that we're *defining* the >> missing httpd function "ap_get_server_version", but we've declared it >> the same way as httpd would do -- that is, marked "dllexport" when >> compiled in httpd and otherwise marked "dllimport" to say that we're >> third-party code importing it from httpd. We're third-party code, of >> course, but *defining* a function marked "dllimport" isn't allowed. >> Removing dllexport/dllimport from the declaration (see attached patch) >> fixes this for me, but I don't know if that's the right thing on > other OSes? > > It works for me. It does not change XS generation, it builds and tests > are working. Feel free to commit that patch to httpd24. > Thanks, now committed in r1502135. >> The build now progress to APR::Brigade, but falls over complaining >> that modperl_error.c references the symbol "perl_module", but that >> isn't defined anywhere. > > Can you send full compiler error? perl_module should be declared in > mod_perl.h and defined in mod_perl.c. > > I've had similar issue when building xs/ModPerl/Const. That was caused > by ModPerl::Const using mod_perl.h, but did not compiling mod_perl.c, > so extern perl_module variable was not defined. Maybe there's similar > situation in Windows for some file too. > > I would check full trace which leads you to undefined perl_module and > check if files have #include mod_perl.h and links with compiler's > mod_perl.c output. > The error is: libaprext.lib(modperl_error.obj) : error LNK2001: unresolved external symbol _perl_module ..\..\..\blib\arch\auto\APR\Brigade\Brigade.dll : fatal error LNK1120: 1 unresolved externals On Windows we build a static library called libaprext.lib containing various symbols otherwise found in mod_perl.lib/dll for APR DLLs to link against so that they don't have a dependency on mod_per.dll -- see the comments in the top-level Makefile.PL around line 187. The list of source files whose objects are put in this library (given by ModPerl::Code::src_apr_ext()) is: modperl_error.c modperl_bucket.c modperl_common_util.c modperl_common_log.c 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.
