Re: What hack in ld.so?
On Sat, Jan 30, 1999 at 04:06:04PM -0700, Jason Gunthorpe wrote:
> On 30 Jan 1999, Alexandre Oliva wrote:
> > Obviously, this would have never been needed if old libraries had not
> > been replaced with (in)compatible versions, but the maintainers of
> > Debian have already taken this step, despite the fact that this would
> Look, it was not us that decided to do this.
Debian was the first distribution to make a decision about the libc6
transition. Certainly we have decided to do it the way we did.
> It was the upstream maintainers, other dists and a huge combination of factors.
It is true that these determined the options and Debians final decision, but
still we decided to follow this.
> It is not in
> our power to choose a different direction to solve these problems, we must
> have libc6 xlib called libX11.so.6 and we must have libc5 called
> libX11.so.6 - that is what all the other dists did, that is the default
> and expected compilation behavoir of xlib and it is what all the new glibc
> binary-only programs are using (ie netscape)
And Alexandre is right that this is - in general - the cause of our problems
with rpath, and it is indeed _wrong_ (in general). That it works in Linux is
only due to a smart hack in the linker, and the hack does obviously not take
rpath into account. So, ask yourself the question: Why do you expect it to
work? Why do you expect it to be fixed in libtool, when libtool has nothing
to do with it?
> If you want to say that is a dumb way then fine, but you have not proposed
> an alternative to solving the versioning problem and you have not proposed
> an alternative way to handle the requirement of identical sonames and
> libtool continues to perpetuate this 'bad' behavoir and makes it worse by
> providing no way to get around it with the standard linux ld.so
There is no right way to get identical sonames but different libraries. The
bad behaviour has to be searched for (and can be found) on the Linux side.
The only solution to this problem would be to allow multiple libraries with
the same soname but different dependencies staying in the same place. There
is currently no way doing so. The way the Linux linker does circumvent the
missing feature does work surprisingly well, but it is still not the correct
> Indeed libtool causes such a severe problem that if you take a libtool
> program, compile it on a libc5 Slackware and try to run it on -any- glibc
> system IT WILL NOT WORK.
How could you expect it to work?
> If you wish to make statement that binaries compiled with libtool work
> only on the host they were compiled for and even then only in specific
> conditions then fine - but that makes it totaly unsuitable for use by any
> of the binary distribution maker.
I think you got it wrong. You are right that Debian had hardly any
alternative for the libc5->libc6 transition. But still, the problem is a
missing feature: An implicit addition to the soname in dependence of the
library dependencies. So you would have /usr/lib/libfoo.2 as rpath, but
really would use /usr/lib/libfoo-libc6.2 or libfoo-libc5.2, you get the
idea. However, the situation is not so easy, because you would need a multi
As this is not possible (currently), the only thing you can do is to grant
that the library is always compatible, as Alexandre correctly pointed out.
We broke this, because it was more convenient for us not to change all
Makefiles of our packages to use different sonames for libc6 libraries with
the same version as their libc5 counterpart. However, the hack in the linker
doesn't work for rpath binaries.
libtool is not the cause for our problems, and rpath isn't, too. Our
problems are the result of the following:
* an "incompatible" upgrade path, together with an incomplete work-around in
* the lack of a way to override rpath.
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09