Re: Shared library defines a RPATH
On Sun, 28 Jul 2002, Marcus Brinkmann wrote:
> ld.so.conf is a Linuxism, and not part of the ELF standard.
Yes. But Debian *is* Linux-tainted. If we're going to fix this, we will
need to add something like ld.so.conf to the other dynamic loaders, or fix
the problems rpath introduce IMHO. It makes no sense to go back to what we
know to be a bad, fundamentaly broken idea.
> You can like it or not, rpath is the standard solution for a library not
rpath is really useful for users, and for the local administrator, thus it
is widely available and used. However, Debian has been very very badly hurt
by rpath before. We know for a _fact_ that rpath in libraries are NOT right
for a distribution, no matter how well it works for others.
* rpath breaks cross-compilation, and any other location-dependant sets of
libraries you might need.
* rpath breaks filesystem moves (you cannot relocate a library without
recompiling EVERYTHING that used rpath with that library).
* rpath breaks major lib upgrades such as the libc5 -> libc6.
> being in /lib (and maybe also /usr/lib if you are into /usr). So, all
> libraries in other places (like /usr/X11R6/lib) should get rpath.
Oh, and why, pray tell? It took a lot of effort to get rid of that crap in
the first place, and now we are to reintroduce its brokeness because people
are too lazy to properly fix stuff that only works with rpath?
What we need is a better solution to the problem (libs in slightly
non-standard places that are somehow standard anyway -- i.e. it is a library
path that is never used to override the system default libraries, but
actually to add MORE standard locations for libraries).
> Now, the criticism that this is not relocatable is valid, and that's why the
> current version of the ELF standard is introducing runpath, which has the
> same semantics has rpath but has a lower precedence then LD_LIBRARY_PATH.
> This should make everyone happy. It is already supported by the GNU libc
> runtime linker, but unfortunately binutils+gcc can not add the runpath to
> the object files yet. :-/ I guess as soon as all GNU tools support it,
> it will be used by libtool instead of rpath.
Maybe it will be enough. It *has* to have lower precedence than
_everything_ else, though. This includes even the standard linker
directories (ld.so.conf in Linux), otherwise it is as bad as rpath was...
If it has lower precedence than everything else, I certainly would have no
qualms about using it in Debian, heck, I would welcome it with open arms :)
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: