[Gllug] How do I make sources available to compile against?

Nix nix at esperi.org.uk
Tue Dec 7 23:26:27 UTC 2004


On Tue, 07 Dec 2004, Tethys moaned:
> 
> Nix writes:
> 
>>> Didn't we have a thread about this sometime last year and conclude
>>> that it was better to use DT_RUNPATH instead of ld.so.conf for
>>> libraries in non-standard locations?
>>
>>Odd: I still have the opposite opinion (and so do the majority of the
>>GNU binutils and GNU libc developers, IIRC).
> 
> Think about the case where you're installing to a directory which is
> shared using NFS by a bunch of other machines. You can either change
> ld.so.conf on each of the clients,

On large farms of identical client boxes, I synchronize it with rsync
when needed --- which it rarely is because most things are in /usr/lib,
or dlopen()ed in which case a path gets specified anyway. (cfengine is
calling to me but I've never got around to learning it. I really must
one of these days.)

>                                    or just use it centrally by using
> DT_RUNPATH. The ease of central management (i.e., make the change
> in one place rather than many) means ld.so.conf loses by a mile here.
> This isn't a contrived example to prove a point, either -- it's
> representative of probably 95% of all my software installs.

I guess I just don't see why you need so many hardwired paths. Since
glibc-2.3.x, ldconfig follows symlinks, so as long as your libs are
symlinked into /usr/lib or /usr/local/lib, ldconfig will find them
anyway.

>>DT_RUNPATH hardwires absolute paths into binaries, which cannot be a
>>good thing. It's better than DT_RPATH because it is at least searched
>>after LD_LIBRARY_PATH and /etc/ld.so.conf libraries, but it's
>>still not a terribly good thing. Nothing that breaks relocation of
>>binaries is good, IMNSHO.
> 
> Agreed. But DT_RUNPATH doesn't break anything any more than they would
> break anyway. If your binary (and its associated libraries) moves, you
> need to update where you look for its libraries. You can do that with
> either /etc/ld.so.conf or LD_LIBRARY_PATH, irrespective of whether the

Hm. True.

I guess I just consider hardwiring things to be inelegant. It's not the
binary's concern where the sysadmin chooses to put things that the
dynamic linker should find before the binary starts, in my view.

> original location was compiled into the binary (or I suppose in theory,
> you could probably patch the binary to update DT_RUNPATH -- but that's
> not an approach I'd recommend :-).

There are tools to do that :)

-- 
`The sword we forged has turned upon us
 Only now, at the end of all things do we see
 The lamp-bearer dies; only the lamp burns on.'
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list