Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Sender: trawick@rdu88-250-035.nc.rr.com
To: dev@httpd.apache.org
Cc: dev@apr.apache.org
Subject: Re: proposed fix for funky Apache binbuild "issue"
References: <m37kn9t3w9.fsf@rdu88-250-035.nc.rr.com>
	<20020415132400.A31117@oolong.il.thewrittenword.com>
From: Jeff Trawick <trawick@attglobal.net>
Date: 15 Apr 2002 15:23:00 -0400
In-Reply-To: <20020415132400.A31117@oolong.il.thewrittenword.com>
Message-ID: <m3k7r8bwbv.fsf@rdu88-250-035.nc.rr.com>
Lines: 88
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Albert Chin <new-httpd@thewrittenword.com> 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 | trawick@attglobal.net
Born in Roswell... married an alien...