Re: -rpath with libtool and Debian Linux
On Jan 27, 1999, Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> wrote:
> On Wed, Jan 27, 1999 at 08:22:09PM -0200, Alexandre Oliva wrote:
>> 3) I don't want to regret having introduced a flag that caused as much
>> or more trouble than -rpath; and
> I don't understand this comment. Which "trouble" with "--rpath" do you mean?
The exact problem the Debian developers have been complaining about.
The more I think about the problem, the more I see that the problem
they're facing is an incomplete hack of ld.so, in that it modifies the
library search path under certain circumstances, but not in all
circumstances that would need it. I.e., if ld.so would replace
/usr/lib with /usr/lib/libc5:/usr/lib whenever it found that the
application was linked with libc5, even if /usr/lib had been
hard-coded in the program's rpath, everything would be working
beautifully.
The fact that libtool always hard-codes /usr/lib in a program that is
linked with a libtool library that is (going to be) installed in
/usr/lib is a side issue, because users may do it on their own, and,
IMHO, they're not to be blamed because of doing that.
> Until now, I only heard from you that rpath is the ideal solution.
Maybe you haven't read (or even received) one of my messages in the
beginning of this discussion, in which I stated that even rpath is
wrong in certain circumstances. For example, if a program is linked
with libfoo, that lives in /foo, and libbar, that lives in /bar, but
there's a compatible (WRT to version numbers, not necessarily WRT
version of libc) version of libbar in /foo, the linker will pick the
one in /foo, not the one in libbar.
In fact, Thomas Tanner's suggestion of dropping -rpath when it would
hard-code a standard library just makes this problem more apparent: if
a (l)user installs a library in /usr/local/lib, but there's a library
with the same name in /usr/lib, the version in /usr/lib will be used
at run-time. This may have very bad consequences, such as the
never-ending problem of (l)users installing gcc 2.[78].* in /usr and
egcs 1.0.* in /usr/local, each one with its particular (and
incompatible) version of libstdc++ (and libg++, for some).
The only way to avoid this potential problem is to hard-code the full
library path in the soname of the library itself, but then, this is
not portable, and it is not desirable because then you can't move a
library at all (read it again: I'm not talking about replacing a
library with an apparently compatible but actually incompatible
version of it :-)
> No rpath makes it harder for a user to determine exactly which system
> libraries he links with. (With rpath, though, it only works when the system
> administrator never changes the library file at this place, too).
It is not a problem to move a library, as long as it can be found in
other hard-coded rpath, in the default search path or in
LD_LIBRARY_PATH. A problem only arises if an apparently compatible
but actually incompatible library is found first, which is exactly the
problem that the Debian developers are facing.
>> 4) I have already suggested a (dirty and ugly, I admit) hack that is
>> sufficient for your needs of not using -rpath at all in Debian
>> packages.
> We can find our own hacks (and do so since a long time). Now we are
> interested in a compatible, portable and general solution. As the libtool
> maintainer, you should be the ideal person to talk about such a solution.
> I think we understood by now that a simple disable flag does not satisfy
> your high ambitions wrt to portability. Let's move on to better solutions.
And, in fact, such a flag, that I said I was willing to accept,
wouldn't actually help you much, because applications are distributed
with their own versions of libtool, and you'd have to modify them all,
or use your own hacked version of libtool to build all applications
(via make LIBTOOL=/hacked/for/debian/libtool), so there'd not be much
point in introducing this change only in libtool 1.3 and newer... :-(
>> I hope you understand my position now. I should also note that I
>> myself have already wanted flags such as -hardcode-libdir for
>> hardcoding the full pathname of a shared library into itself (it's
>> mentioned in libtool/TODO) and -no-implicit-rpath (which is what you
>> happen to be asking for), but I have some trouble deciding who should
>> be responsible for deciding which flags to use for which libraries and
>> programs.
> Maybe you should not be the one to decide at all?
I'm certainly not.
> Offer flexible solutions, where the last person can override the
> (possible) default given by others.
That's the hard part. Overriding may have to occur in a per-library
and/or per-program basis, so I haven't been able to come up with a
satisfactory solution.
> This means, the package can provide a default, which can be overridden at
> compilation time. Finally, the installer can override both.
That's exactly what I'm looking for. But I wouldn't like to install a
quick hack now that would later reveal to be a step in the wrong
direction. That's why I'm being so conservative about all this issue.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
Reply to: