Re: Shared library defines a RPATH
On Sun, 28 Jul 2002, Richard Atterer wrote:
> On Sun, Jul 28, 2002 at 02:12:01PM -0300, Henrique de Moraes Holschuh wrote:
> > Still, it breaks cross-compilation (which is not a very important
> > point for most people, but...),
> In what way does it break cross-compilation?
It may point to the wrong place in the target machine, since a lot of build
systems use the location of the for-cross-compiling libs in the host (which
won't be in /usr/lib, you bet :-) ). Yeah, this is not inherently a rpath
problem, but rather a bug in the build environment+system, but it is
triggered by rpath usage (so suddenly adding rpath means fixing this bug,
and it is about the same amount of work of using a LD_* trick, or adding
stuff to ld.so.conf...).
Also, it is suddenly impossible to override where the libraries are:
(from ld.so source, d-link/readelflib1.c)
* The ABI specifies that RPATH is searched before LD_*_PATH or
* the default path of /usr/lib.
* Check in rpath directories
So, you cannot do cross-compiling tricks to easily switch to an optimized
set of libraries back-and-forth, for example: rpath cannot be overriden.
"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
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org