Jan Kaluža wrote on 2013-07-11:
> 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 :(.
>
Where/how have you hard-coded the *path* to that library, though? I only see
the library *name* hard-coded:
# FIXME: This should be done automatically somewhere in Apache2::Build
$libs .= qq{ -laprutil-1 };
>> 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.
>>>
[...]
>> 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:
>
Ok, that sounds like a reasonable plan. I will look into later.
