On Sun, 2002-02-17 at 14:59, Zack Weinberg wrote:
> One reason why *developers* hate -rpath and like LD_LIBRARY_PATH, is
> that a lot of systems search -rpath directories before anything else.
> So if you have a library installed in say /usr/local/lib, you're
> trying to test a new version with the same soname, and the software
> that uses the library was built with -rpath /usr/local/lib, you're
> screwed. Well, sometimes LD_PRELOAD will do the job, but not always.
Yeah, this sucks. But it's actually specified by the ELF spec, bogus as
it is; systems like Solaris which implement the more useful search order
are in violation of the ELF spec. This behavior is part of the reason
why (in my regular job) I have to build releases in a chroot area rather
than just building into a temporary area and convincing everything to
link against libraries and whatnot in the temporary area. (Although,
the simple act of convincing was getting pretty tough and error-prone as
it was, mostly thanks to GNOME.)
> I kind of wish there was a utility that could edit DT_RPATH entries in
> an executable binary. This would allow one to create binaries with
> -rpath pointing inside the build directory (which avoids the need to
> set LD_WHATEVER during testing), and then adjust them to point to the
> installed-library directory at installation time.
It would also let you build relocatable binary packages which worked by
editing the run path. (Assuming you could also solve the problem of
getting binaries to find their data files.)
As others have pointed out, invoking the linker during the install rule
(or during a package install) is questionable at best, so re-linking
with libtool isn't a great answer. Really, we just have to live with
the absence of such a tool.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:08 2006