Re: What hack in ld.so?
On Jan 30, 1999, Jason Gunthorpe <jgg@ualberta.ca> 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 aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
Reply to: