Hi, 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 thing. > 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 dimensional table. 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 linker. * the lack of a way to override rpath. Thanks, Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@ Marcus Brinkmann http://www.debian.org master.debian.org [EMAIL PROTECTED] for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
