Re: -rpath with libtool and Debian Linux
Date: Tue, 2 Feb 1999 20:16:15 -0600
From: John Goerzen <jgoerzen@complete.org>
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.
This argument sounds like a quibble to me. My home directory hasn't
moved since I installed this system eight years ago. If you really
can't stomach the home directory here, then instead consider
/usr/local/lib, or /opt, or any place which a sysadmin might set up
for the permanent installation of user controlled binaries.
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.
It's a fair bit harder when you consider my final point about many
people expecting to run the resulting program.
> 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).
No, I mean /etc/ld.so.cache. /etc/ld.so.conf is just a list of
directories. If the dynamic linker just searched that list of
directories, the Linux library search algorithm would be much easier
to understand. In reality, ldconfig builds /etc/ld.so.cache with
flags indicating the type of each shared library and which version of
libc was built against. The dynamic linker then uses those flags when
deciding which library to pull in.
Without some such scheme, moving the shared libraries without changing
the sonames would not have worked, because the dynamic linker would
simply have found the glibc version of a shared library even for a
libc5 program, since the glibc shared library is first in the link
order (or, if it isn't, then the glibc program would fail instead,
finding the libc5 version of the shared library).
> 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...?
No, I mean the person who writes the software package in the first
place, as in ``I am the GNU binutils maintainer.''
> 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.
I disagree. There are uses for -rpath beyond using it for system
libraries. These uses are just as valid on Linux as they are on any
other system.
Ian
Reply to: