Re: -rpath with libtool and Debian Linux
On Tue, Feb 02, 1999 at 08:41:06PM -0500, Ian Lance Taylor wrote:
> You're quite right that ld.so.conf may not be the same when a program
> is linked and when it is run. However, it is appropriate for libtool
> to use -rpath if the shared library is installed in a user's
> directory; otherwise, the user would have to set LD_LIBRARY_PATH,
> which is inconvenient, particularly if many people expect to run the
> resulting program.
This is not correct either. User home directories are never guaranteed to
remain at the same place, and in some situations (ISPs, academia, etc.) may
actually frequently move. Hence the reason that people are encouraged to
use $HOME instead of hard-coding their home directory.
Not only that, but I just make a $HOME/lib directory, set that in
LD_LIBRARY_PATH, and I'm set. That's not so hard.
> Therefore, it's not OK to eliminate -rpath entirely from libtool.
> However, it's probably OK to avoid using -rpath for any system
> directory, one which the dynamic linker will search.
I did not advocate eliminating it completely, esp. in light of the
(apparent) fact that it's necessary on other platforms.
> The use of /etc/ld.so.cache, rather than a simple directory search,
I think you mean ld.so.conf here (cache is basically the result of
ld.so.conf plus the list of installed libraries).
> means that there is no actual list of system directories on a Linux
> system other than /lib and /usr/lib. However, /etc/ld.so.conf is a
> reasonable approximation, one which will probably not mislead an
> ordinary program.
> It would also be possible to add an option to libtool to avoid the use
> of -rpath. However, no package maintainer would ever use such an
I think we're having a bit of difficulty communicating here. Do you mean
Debian package maintainer or...?
> option, since it would never be correct without knowing the --prefix
> option used for configure. Only an organization like Debian would use
> it. Alexandre sent out a patch which disabled -rpath, which Debian
> could use just as easily as a special option. I don't have a copy of
> that patch.
I would maintain that -rpath should be disabled by default on Linux. Adding
an option to disable it is not the correct solution, but it does solve the
immediate problem at hand, so I would not complain about that certainly, but
it leaves the underlying issue unfixed.
Reply to: