On 07/11/2013 10:41 AM, Steve Hay wrote:
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.
Right, I had the same problem with automation and I decided to hardcode
it for Linux :(.
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.
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.
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-Const.xs.patch
Regards,
Jan Kaluza
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org
