Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 06 Jan 1996 11:14:50 EDT
From:      "Kaleb S. KEITHLEY" <kaleb@x.org>
To:        joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Cc:        hackers@freefall.FreeBSD.org
Subject:   Re: Demand loading (Re: FreeBSD, Zappa & PCI) 
Message-ID:  <199601061614.QAA14121@exalt.x.org>
In-Reply-To: Your message of Sat, 06 Jan 1996 16:15:31 EDT. <199601061515.QAA14865@uriah.heep.sax.de> 

next in thread | previous in thread | raw e-mail | index | archive | help

> > 
> > > >  I'd also be keen to get rid of ldconfig 
> > > > and ld.so.cache.
> > > 
> > > Why?
> > > 
> > > I've been missing them on SysV.  (For configuration purposes, let the
> > > possible performance gain from a shorter lookup time alone.)
> > > 
> > 
> > In SVR4 (or Digital Unix nee OSF/1) you set the RPATH in the executable
> > to dictate where to look for shared libs if the shared libs aren't in the
> > "usual" place; completely obviating the need for ldconfig and ld.so.cache. 
> > Packages put the libraries where ever they want, the program knows where 
> > to find them. You don't need hints like ldconfig and ld.so.cache.
> 
> Who puts the RPATH into the executable? At least, simply linking it
> e.g. against an X11 library with ld doesn't put it there.  

When you have ELF, ld can put it there.

> In my case,
> it was an application that has been linked against some X11 libs but
> that is regularly started via inetd, so there wasn't an easy way for
> tweaking the environment.  The latter is not the normal way to go
> anyway, think of setuid binaries.  

Setuid *root* binaries ignore LD_LIBRARY_PATH, even with ELF.

> My only solution was to symlink the X cruft into /usr/lib.  Not very 
> exciting.

This isn't necessary if you've ldconfig'd /usr/X11R6/lib into the
ld.so.cache?

> What about binaries where i want to shuffle the shared libs around
> later?  

Yuck. :-) With ELF it's reasonably easy to write a utility to rewrite 
the RPATH in a program if you really wanted to move its libraries around.

> (E.g., they are linked against Motif, and i'd like to keep my
> copy of Motif in a separate subtree?)

Keeping Motif (source?) in a separate subtree is one thing. You install
the libraries somewhere, right? /usr/X11R6/lib? You've added /usr/X11R6/lib
to your ld.so.cache, right? So with ELF, each application has it's own
ld.so.cache, except that it's called RPATH, and it's stored in each
application instead of the global /etc/ld.so.cache.

Actually the whole RPATH thing is optional. The run-time loader knows
how to find well known directories, like /lib, /usr/lib, and maybe
/usr/local/lib too. Only applications that want libraries that aren't
in the well known places need to use the RPATH.

> You haven't convinced me yet that the SysV solution is better than
> ld.so.hints.  

I've given up long ago of trying to convince the people on -hackers of 
anything. :-)

> No, i'm not defending BSD since it's just BSD, but
> ldconfig used to be one of the tools i love in BSD.  It gives the
> administrator a fine-grain control about the location of shared
> libraries, without fiddling with the environment.

Other than the fact that ld.so.cache is a minor security hole. Okay, any
sysadmin worth their salt isn't going to add world writable directories 
to the ld.so.cache, but you never know.

I don't know how many people I've had to tell about ldconfig and the
ld.so.cache. Most people shipping BSD systems are finally smart enough 
to put /usr/X11R6/lib into their ldconfig/ld.so.cache by default now, 
which is fine until someone (like me) uses a different ProjectRoot in 
their X build, which is when that strategy falls apart. At least I know
to go fix my /etc/rc.local to build my ld.so.cache correctly. :-)

All in all it'd be nicer (IMHO) if I didn't even have to muck with ldconfig
and ld.so.cache.

--

Kaleb KEITHLEY



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601061614.QAA14121>