[Gllug] libs, but where?

[Nix]

On Wed, 24 Jul 2002, tet at accucard.com stipulated:
> While this is true, both are the wrong solution. ld.so.conf is a nasty
> linuxism, and LD_LIBRARY_PATH should be avoided where possible for
> a number of reasons. The best solution is to compile in a run time
> library path by using "gcc -Wl,-rpath,/path/to/my/libs/directory"

DT_RPATH (and -rpath, which uses this section) is a despicable
kludge. There is considerable support on the binutils (and gcc) lists
for dropping the option from ld entirely: only the fact that libtool
uses it, the fact that it is sometimes (*very* rarely) actually useful
(for libraries like plugins that a very few applications need to find in
fixed locations, but which the application for some reason cannot
dlopen()) and the needs of standards-compliance are staying our
collective hands.

I cannot see how you can *possibly* say that an option that forbids
moving shared libraries around without relinking all binaries linked
against them is preferable to one that allows moving of shared libraries
at any time with no more difficulty than changing one path in one file
and running /sbin/ldconfig.

(I know that it is --- nearly --- impossible to use either a GNU
stow-managed or AFS system with a system that heavily relies upon
DT_RPATHed binaries, because such systems very frequently keep shared
libraries in versioned subdirectories, so all of a sudden you can't
replace one minor version with another without a massive relink, even
though their soname is the same.)


I used to like DT_RPATH. Then I had to rename a single directory, and
the ensuing >200 otherwise-unnecessary relinks changed my mind. (OK, so
I didn't actually do the relinks --- I wrote a program that used libbfd
to parse the binaries apart and edit the DT_RPATH section --- but most
people would likely have been in the soup with no option bar
relinking. You can't say that that is preferable to editing
/etc/ld.so.conf!)

> http://www.visi.com/~barr/ldpath.html

I agree with that author that LD_LIBRARY_PATH is bad for anything other
than library testing (and, very rarely, kludges involving multiple
incompatible libraries with the same soname, but let's not go
there).

However, he doesn't bother to give any reasons why /etc/ld.so.conf is
bad, he just asserts it: I'm left thinking `ignorant prejudice'.
`Almost as bad as LD_LIBRARY_PATH' is purest nonsense: the three largest
problems with LD_LIBRARY_PATH (that it was an environment variable with
no guaranteed central place to set it, and that it was an environment
variable and so couldn't be changed for the entire system
instantaneously, and that it was an environment variable and so couldn't
apply to suid or sgid programs) do not apply to ld.so.conf. (Oh, and
ld.so.conf doesn't impose the path-searching overhead of LD_LIBRARY_PATH
either, because of ld.so.cache.)

ld.so.conf was quite carefully designed and is a very nice feature. I
for one couldn't give without it (but then as I have 121 lines in my
ld.so.conf, I may be an unusual case). I ram into the limitations of
DT_RPATH on non-Linux ELF boxes all the time, and each time I wish
for ld.so.conf or something like it.

(/etc/ld.so.preload, though, *is* mostly useless. But only mostly.
Perhaps some kind of stack-guarder could be loaded there... but pray
that your preloaded library never breaks!)

-- 
`There's something satisfying about killing JWZ over and over again.'
                                        -- 1i, personal communication

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug