On Jan 27, 1999, Marcus Brinkmann <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil
