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 21:38:05 GMT
On Mon, Apr 15, 2002 at 03:23:00PM -0400, Jeff Trawick wrote:
> 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.

Ick.

> > > 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?

Should be it. You'll then just run libtool --mode=link. The problem
though is the .la file contains parts of the build environment which
might not exist on the target. How would you deal with this? Take a
look at the .la file of an executable to see what I mean.

BTW, for executables, I think you only need .o whereas for libraries,
you need .o and .lo. Dunno if .a files are regenerated at install time
(might be as ranlib might need to be run on them for certain
platforms).

-- 
albert chin (china@thewrittenword.com)

Mime
View raw message