apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: Making APU_DSO_LIBDIR configure-able
Date Tue, 05 Aug 2008 22:54:13 GMT
William A. Rowe, Jr. schrieb:
> It's already done; we accept the filesystem-convention for a search path.
> Why would we add additional overhead of a second convention?

At the moment the default apr-util first searches in the the entries in
LD_LIBRARY_PATH (or whatever the appropriate variable per platform is)
and their apr-util-VERSION sub directories and as a last resort it looks
at the same sub directory below the installation directory given to
configure. It does *not* use the RPATH/RUNPATH of apr-util itself as a
base path for the sub directory  (correct me if I'm wrong).

So if you move your libs after installation (or: you don't know the
install path during build) you need to adjust your search path via
LD_LIBRARY_PATH. Either by giving the full path to the sub directory, or
by giving the path to the parent directory.

This works, but for some platforms there exists an easy way to express
relative search paths for the runtime linker. Here we have an excellent
use case for that, because the helper libs are always in the same sub
directory. Supporting that with an optional configure switch would allow
to move the libs around without fiddling with LD_LIBRARY_PATH.

For httpd (needing to load libapr etc.) and apr-util (needing to load
libapr) this can be done by the build time user without explicit support
from the build system by giving an appropriate runpath when calling gcc,
but the helper library loading by apr-util doesn't use the RPATH/RUNPATH
and so one either has to change APU_DSO_LIBDIR using
$ORIGIN/apr-util-VERSION at build time (which is not possible today), or

> What we did wrong was fail to peer into apr-util-1 in each of those paths.
> That's now fixed for the next release.

I noticed that, I'm using HEAD of 1.3.x. Before the fix I added the full
directory to httpd's envvars script. It just seems to be a much more
elegant way of handling relative dependencies.

Thanks for listening!

> Rainer Jung wrote:
>> Hi,
>> some OSes have a handy way of using relative search pathes for the 
>> runtime linker. E.g. Linux and Solaris both support the use of the 
>> string '$ORIGIN' at the beginning of a search path element, which is a 
>> placeholder for the directory, in which the shared object needing 
>> another one is located. So on these platforms
>> #define APU_DSO_LIBDIR "$ORIGIN/apr-util-1
>> would make the apr-util and ldap helper lib nicely relocatable in the 
>> file system.
>> Although libtool doesn't support $ORIGIN (since it isn't portable), it 
>> would be nice to make APU_DSO_LIBDIR customizable via configure, so 
>> that one could set it to $ORIGIN during the build.
>> I know, that at the moment apr-util automatically chooses the library 
>> installation path given to configure, but in all cases were you want 
>> to make the installation path choseable after the configure step, that 
>> doesn't help.
>> I already tested, that $ORIGIN also works within dlopen() (at least on 
>> Solaris, Linux still to test), which is relevant here.
>> If there is some interest in this, I could provide a configure.in patch.
>> Regards,
>> Rainer

View raw message