> -----Original Message----- > From: Marcus Brinkmann [mailto:[EMAIL PROTECTED] > Sent: Sunday, January 31, 1999 12:53 AM > To: Jason Gunthorpe; Alexandre Oliva > Cc: Debian Developers; [EMAIL PROTECTED] > Subject: Re: What hack in ld.so? > > > Hi, > > On Sat, Jan 30, 1999 at 04:06:04PM -0700, Jason Gunthorpe wrote: > > On 30 Jan 1999, Alexandre Oliva wrote: > > >
<snipped skipped> > > 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? I do *NOT* expect it to work: I everyday *USE* binaries that were *NOT* compiled by libtool but were indeed compiled on a libc5 system several years ago; they *STILL WORK* on my new libc6-based RedHat-5.2 system! I just want to be able to obtain the same functionality with libtool... No more, noless :-) > > > 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. > The problem is neither -rpath or libc5/libc6; the fault is neither Alexandre nor Debian, RedHat or Devian :-). The problem is that I want to be able to obtain with libtool the same service I can obtain usually without it (although with a lot more difficulties): Build shared libraries and executables, that will work on various libc5 or libc6 based Linux distributions (as well as, as far as I'm concerned, on Solaris, hpUX, AIX and WindowsNT :-)) I do not ask Alexandre to devise *the perfect solution* that will allow me to build things without having to bother at all even in the very complicated cases where I link against totally non-standard stuff that I found in some exotic place on my system. I would like libtool to be able, without bothering me too much, to provide a correct answer on the maximum number of systems in the maximum number of cases. If I'm in a situation where -rpath is *needed*, OK, let *me* decide that (when I say me, let the package builder decide of this). If I'me pretty sure everything will work by default, without using -rpath, let me do it this way. The package builder is the one that knows, not Alexandre; and the package installer is the one that has to be provided with a mean to turn the problem if there is one. In the current situation Alexandre (that is libtool) is deciding in place of the package builder, and with a scheme where the package installer is stuck if things do not work right out-of-the-box. Regards, Bernard PS. Anyway Alexandre you've made a great job with libtool; why I'm a bit upset here is that I have the feeling that I will *not* be able to use this marvelous tool that is libtool... -------------------------------------------- Bernard Dautrevaux Microprocess Ingéniérie 97 bis, rue de Colombes 92400 COURBEVOIE FRANCE Tel: +33 (0) 1 47 68 80 80 Fax: +33 (0) 1 47 88 97 85 e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] --------------------------------------------