Re: Relocation (Re: Package system)

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Tue, Sep 02, 2003 at 10:42:34PM +0200, ibotty wrote:
> > Changed ld.so is IMHO not a major concern - the other alternative to per
> > user ld.so.cache is operation without it. How badly is a ld.so.cache
> > needed these days anyways? You could also support customised search paths
> > and priorities.
> 
> this is currently done in the gnustep initializing scripts.
> they set $LD_LIBRARY_PATH.
> 
> but $LD_LIBRARY_PATH defeats prelinking (prelinking makes no sense when
> different libraries are possibly used).
> and ld.so.cache is faster. on linux 2.3 when i altered ld.so, i got 25%
> better startup time than without, with only kde1.2 (few libs) linked to
> this "hello world" binary. 

As Jeroen pointed out, there are good reasons why $LD_LIBRARY_PATH is
often the wrong solution to the wrong problem. Most of those library
issues of GNUstep can in fact be handled by -rpath without any problem.
If we don't want to deploy prelinking, we could ultimately drop ldconfig.
NetBSD does it and there are basically only two issues. The first one is
the build of third party software, which often needs patching esp. all
those configure scripts out there. The second one is relocation, which
needs runtime path changing. I suppose that could be handled mostly
automatically, given a proper list of binaries, libraries and a -rpath
editor for ELF.

The question of using -rpath vs. ldconfig doesn't affect prelinking.
It should not matter how the search path are found, only the order
of dependent libraries and there location is of interest. Having
"static" location just increases the number of binaries which can
utilize prelinking.

Joerg

> 
> this may be less now, as hardware is cheap, but you get the idea.
> 
> btw: is someone interested in prelinking? on freebsd5, there is an effort to
> prelink. but i do not know, how far this is.
> if there is interest, i may dedicate some of my spare time to it (in one
> month, more or less).
> 
> ~ibotty