perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: the issue with APR_HAS_THREADS
Date Fri, 08 Apr 2005 22:57:01 GMT
Philip M. Gollucci wrote:
>> I think that means a simple thing. You had Apache first installed with 
>> libapr as a part of it and that libapr was built with threads so the 
>> header file was:
>>  apache/include/apr.h:#define APR_HAS_THREADS           1
>> now you build a new libapr, and its header files are installed 
>> elsewhere. But you still have apache/include/apr.h from above, and 
>> that's the one that mod_perl's build process picks. Is that the case?
> I think you said it backwards...
> I had 1 apr installed in /usr/local/. outside of httpd without threads. 
> this came from the install of subversion via freebds 
> ports(/usr/ports/devel/subversion) .
> I then had one installed with httpd w/ threads in 
> /home/pgollucci/dev/inst/httpd/2.1.5-dev/prefork/ based on my subversion
> checkouts of httpd2,apr,apr-util.  (I had to build/install subversion as 
> above first to do this)
> The first was in my path so it was used as the lib despite my --with-apr 
> option to configure.
> The header file [apache/include/apr.h] got generated with threads 
> because of --enable-maintainer-mode I passed to httpd which did imply 
> threads as it should.
> So now I have a header/library mismatch. It got worse so that my httpd
> was linked with _BOTH_ APRs.  The non threading one was first in the ldd
> output of httpd -- I guess its first come first serve.  HTTPD managed to 
> compile and run somehow.  This double linking blew up in face when I got 
> to the mp2 make stage.
> After wasting a lot of my time... and probably others... I'd say this is 
> likely a mix up on my part and/or httpd's configure did not honor my 
> --with-apr options... I'll follow this up on

Assuming that you load a correct libapr(-util).so (i.e. it's the same 
libapr(-util).so as the one reported by the script provided by 
MP_APR_CONFIG value) this is a bug in modperl. It shouldn't assume that 
apr headers are in the apache/include directory and query the apr-config 
for the location of the headers.

If not (i.e. you didn't not supply MP_APR_CONFIG at build time), then it's 
your problem, but we should try to detect that and explain to the user 
what went wrong. The problem is that sometimes libapr sits in /usr/lib and 
it of course gets loaded instead of the right lib from apache/libs/

As always patches are welcome :)

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

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

View raw message