Re: [HACKERS] dynamic libraries

On Mon, 12 Oct 1998, Thomas G. Lockhart wrote:
> A nice feature of putting libraries into /etc/ld.so.conf is that the
> libraries are found automatically as a system resource. Hard-linking
> the paths (or possible paths) in the executable seems to be a bit
> restrictive.

I'm not sure how that is a feature at all.  Having loads of junk in your
library search path really slows things down.

An ELF system does not have an ld.so.conf.  (Note that FreeBSD/ELF does
have an ld.so.conf but I believe this is only for transition purposes.)

If you (the system administrator) install a package, you know where it is
installed.  You are able let the binary take care of tracking where its
libraries are supposed to be, not the system.

> Since ld.so.conf is a very useful feature for linking with at least some
> kinds of libraries, perhaps you can suggest or point to the guidelines a
> system builder would use to choose what mechanism to use for a specific
> case? I could image guidelines that would say to put system-wide
> resources into ld.so.conf, and user-installed resources into
> LD_LIBRARY_PATH or the "-R/r" flags.

Having to set LD_LIBRARY_PATH to make things work is bogus; what if
someone forgets to set it?  What if a user can't edit ld.so.conf (ignoring
the fact that it won't exist on a real ELF system).

Compiling the information into the binary is much prefered.  If for some
reason you have to move the libraries, using LD_LIBRARY_PATH to keep them
running is a good bandaid until you can recimpile or edit the compiled in
paths (if your system supports such tools.)

> The recent bump in libpq version number (entirely appropriate imho)
> illustrated the downside to using ld.so.conf in that my root account had
> to rerun ldconfig to make the new library known to the system. otoh it
> was really easy to do...

Elf systems have no 'major' version number.  On an a.out system you'd get
something like 'libpq.so.1.1'.  ELF would call this library 'libpq1.so'
which would be a link to 'libpq1.so.1'.  If the 'major' number is to be
changed (ie: an incompatible interface change was made) you must change
the name of the library.  For a.out it would become 'libpq.so.2.0' and ELF
'libpq2.so -> libpq2.so.0'.

Anyhow, in summary, depending on enviornment variables or a hacked linkrer
that supports 'ld.so.conf' is a bad thing on a real ELF system.  ELF
provides for compiled in search paths and they should be used.  This
reduces the additional steps a user must take to have a running system and
does not violate the POLA.  Since the compile/build process knows where
the install destination will be, nothing prevents it from doing the right
thing and using '-R' or '-rpath' ld(1) directives to set the search path.

I've done the whole LD_LIBRARY_PATH and it sucks; I had one that was
nearly a page long.  How the heck do you maintain such a thing and make
sure nobody else introduces a trojaned library that appears earlier in
your path?

--
| Matthew N. Dodd  | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| winter@jurai.net |      This Space For Rent     | ix86,sparc,m68k,pmax,vax  |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage?   |