apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Albert Chin <new-ht...@thewrittenword.com>
Subject Re: proposed fix for funky Apache binbuild "issue"
Date Mon, 15 Apr 2002 18:24:01 GMT
On Mon, Apr 15, 2002 at 10:47:34AM -0400, Jeff Trawick wrote:
> For Apache binary distributions, an environment variable (e.g.,
> LD_LIBRARY_PATH) is used at run-time to locate libapr, libaprutil,
> libexpat, etc. because the path etched into the httpd executable is
> the path used when creating the binary distribution, not the path used
> for the actual install.
> But there is a problem with this: LD_LIBRARY_PATH is always searched
> after the etched-in path.  Also, the etched-in path is searched before
> the system path.

According to ld.so.1(1) on Solaris 8/SPARC:
     The runtime linker uses a prescribed search path for  locat-
     ing  the  dynamic  dependencies  of  an  object. The default
     search paths are the runpath recorded in  the  object,  fol-
     lowed  by /usr/lib for 32-bit objects or /usr/lib/64 for 64-
     bit objects. This latter component can be modified  using  a
     configuration  file  created  with  crle(1).  The runpath is
     specified when the dynamic object is constructed  using  the
     -R  option to ld(1). LD_LIBRARY_PATH can be used to indicate
     directories to be searched before the default directories.

Therefore, LD_LIBRARY_PATH is searched *before* the etched-in path. Is
there any platform where this is not the case?

> I think we'd be better off if there were no path etched into httpd for
> a binary distribution.  (This could be useful for more than just the
> binbuild.sh scenario.)  Unfortunately, it isn't clear how to do this
> with libtool.  When apr.la is created -rpath is required.  It then
> goes into apr.la and I think that is what results in the etched-in
> path for httpd.
> Any ideas on how to deal with this issue?
> It would be nicer to just replace the etched-in value at install
> time.  I don't think that libtool can do that unless you do a re-link
> on the target machine.  We could binary-edit the path within the
> executable but that doesn't sound very maintainable.

The correct solution is re-linking on the target. Libtool does this by
default when installing the binary.

BTW, are you talking about pre-compiled binaries provided by
apache.org or pre-compiled binaries available in RPM/DEB/etc format?
If the latter, I disagree with the solution of a NULL run-time search
path in the binary.

albert chin (china@thewrittenword.com)

View raw message