Albert Chin <[EMAIL PROTECTED]> writes:
> > 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?
On Linux the etched-in path is searched before LD_LIBRARY_PATH.
Here is an strace on Linux showing the etched-in path searched before
LD_LIBRARY_PATH:
execve("bin/httpd", ["bin/httpd"], [/* 36 vars */]) = 0
brk(0) = 0x8094b64
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/home/trawick/apache/httpd-2.0.35/bindist/lib/i686/mmx/libaprutil.so.0",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/trawick/apache/httpd-2.0.35/bindist/lib/i686/mmx",
0xbffff4b4) = -1 ENOENT (No such file or directory)
open("/home/trawick/apache/httpd-2.0.35/bindist/lib/i686/libaprutil.so.0",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/trawick/apache/httpd-2.0.35/bindist/lib/i686", 0xbffff4b4)
= -1 ENOENT (No such file or directory)
open("/home/trawick/apache/httpd-2.0.35/bindist/lib/mmx/libaprutil.so.0",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/trawick/apache/httpd-2.0.35/bindist/lib/mmx", 0xbffff4b4)
= -1 ENOENT (No such file or directory)
open("/home/trawick/apache/httpd-2.0.35/bindist/lib/libaprutil.so.0",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/trawick/apache/httpd-2.0.35/bindist/lib", 0xbffff4b4) = -1
ENOENT (No such file or directory)
open("/tmp/2.0.35/lib/i686/mmx/libaprutil.so.0", O_RDONLY) = -1 ENOENT
(No such file or directory)
stat("/tmp/2.0.35/lib/i686/mmx", 0xbffff4b4) = -1 ENOENT (No such file
or directory)
open("/tmp/2.0.35/lib/i686/libaprutil.so.0", O_RDONLY) = -1 ENOENT (No
such file or directory)
stat("/tmp/2.0.35/lib/i686", 0xbffff4b4) = -1 ENOENT (No such file or
directory)
open("/tmp/2.0.35/lib/mmx/libaprutil.so.0", O_RDONLY) = -1 ENOENT (No
such file or directory)
stat("/tmp/2.0.35/lib/mmx", 0xbffff4b4) = -1 ENOENT (No such file or
directory)
open("/tmp/2.0.35/lib/libaprutil.so.0", O_RDONLY) = 3
> > 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.
Any idea what we have to change to make that happen? That requires
shipping all the .o .lo .a .la, right?
> BTW, are you talking about pre-compiled binaries provided by
> apache.org or pre-compiled binaries available in RPM/DEB/etc format?
binaries provided by apache.org
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
