On Jan 30, 1999, Jason Gunthorpe <[EMAIL PROTECTED]> wrote: > On 30 Jan 1999, Alexandre Oliva wrote:
>> Thanks God I've got only one group of developers almost forcing me to >> change something that is correct, and whose change wouldn't even help >> them work around a problem they're facing. > <shrug> I'm sure you have lots of screwball stuff to support defective and > broken systems in libtool, I don't see how doing something 'wrong' to > support another broken system like Linux is so bad. The point is that you've just been asking for libtool not to use -rpath at all, but this would only work for people who create .deb or .rpm binary packages, and not for any user that would be interested in building a package from the sources and installing it in non-standard directories. I have been somewhat hesitant about selectively dropping directories that are searched by default from the hardcoded rpath, but I think we can do it without much damage. There will be some, but whenever such a problem occurs, it is only because there was potential for its occurrence before, so we can live with it. It's just waiting for someone to implement it. > You cannot deny that it is necessary, and that it effects more that just > Debian and our users but everyone using a libc5/libc6 linux system. I can, that that's what I've been doing since the `Debian x Libtool War' started, a few days ago. I've insisted that the problem is not in the fact that libtool uses rpath, it is that libraries have been replaced with incompatible ones, and the code in ld.so that tries to accomodate for this replacement does not work when a program has a hard-coded library path. > It is not a problem we are 'facing' it is one we already faced and > arguably made the wrong choice - So now all linux systems have this > horrifying defect. Oh Well. That's Life - we can't fix it. You can, but the problem cannot be fixed within libtool (which doesn't mean libtool can't help); it can only be fixed in ld.so >> Ulrich Drepper has already mentioned that it's quite easy to modify >> the hard-coded rpath of a program without recompiling it, and that >> there's even a tool that will do that. > I actually think we have a program that does it as well, but somehow > adding something to a file in /etc vs 'stripping' every binary you install > on your system does not seem comparable. You don't have to strip every binary you install, only binaries that stop working after an upgrade. The upgrade program itself might search for programs linked with the old version of libc and with a (now) wrong hard-coded library path and fix them. -- 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