RE: What hack in ld.so?
> -----Original Message-----
> From: Marcus Brinkmann [mailto:Marcus.Brinkmann@ruhr-uni-bochum.de]
> Sent: Sunday, January 31, 1999 12:53 AM
> To: Jason Gunthorpe; Alexandre Oliva
> Cc: Debian Developers; bug-libtool@gnu.org
> 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: dautrevaux@microprocess.com
b.dautrevaux@usa.net
--------------------------------------------
Reply to: