perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Kaluža <>
Subject Re: [httpd24 branch] merge with trunk?
Date Thu, 11 Jul 2013 09:06:52 GMT
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:
>> 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())
> 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:

Jan Kaluza

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message