Re: Shared library defines a RPATH
On Sun, 28 Jul 2002, Mikael Hedin wrote:
> Henrique de Moraes Holschuh <hmh@debian.org> writes:
> > No, it is not. We don't want rpath because we want our libraries to be
> > "relocatable" file-system wise. So, there are absolutely no exceptions.
>
> Please explain a bit further, I don't see the point here. The libs
> and the apps are all in /usr/lib/ogle and come from the same package.
This certainly reduces the problem one would have, since the libs and apps
are all in one place. Still, it breaks cross-compilation (which is not a
very important point for most people, but...), and any other trick one might
need to do in the linker for one reason or another (and do notice that this
would be a global change on the way the system works, and only packages
using rpath would fail with it -- the libc upgrade is a good example of such
a trick, and of a valid reason to use it).
I fail to see why we should allow exceptions to the rpath rule at all. So
far, it has always been asked by people who did not want to go to the extra
loops of getting rid of rpath (which can be quite difficult to do right in
some build environments, and libtool doesn't help), or of writting wrappers
or the code to deal with ld.so.conf.
The problem is: rpath looks like the standard, simple answer to the problem,
while it actually has a lot of side-effects that are not really desirable
(and not obvious, either).
I cannot foresee another libc-like upgrade that would break hideously rpath
binaries, but that doesn't mean there won't be any...
--
"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: