-Original Message-
From: Alexandre Oliva [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 31, 1999 12:29 AM
To: Jason Gunthorpe
Cc: Debian Developers; [EMAIL PROTECTED]
Subject: Re: What hack in ld.so?
On Jan 30, 1999, Jason Gunthorpe [EMAIL PROTECTED] wrote:
If you wish
-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
-Original Message-
From: Gordon Matzigkeit [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 31, 1999 5:41 AM
To: debian-devel@lists.debian.org; [EMAIL PROTECTED]
Subject: Ian's solution [was: What hack in ld.so?]
Hi, all!
There's been so much traffic on this thread, that I
On Feb 1, 1999, Bernard Dautrevaux [EMAIL PROTECTED] wrote:
Once more this proves that -rpath is harmful: If Devian use -rpath thsi
will *force* the other distribution makers to place Devian-specific
stuff in /dev (and if Devian was crazy, placing standard stuff in /dev,
their programs will
On Feb 1, 1999, Bernard Dautrevaux [EMAIL PROTECTED] wrote:
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
-Original Message-
From: Alexandre Oliva [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 30, 1999 11:39 PM
To: Buddha Buck
Cc: Jason Gunthorpe; Debian Developers; [EMAIL PROTECTED]
Subject: Re: What hack in ld.so?
On Jan 29, 1999, Buddha Buck [EMAIL PROTECTED] wrote:
[exact
On Feb 1, 1999, Bernard Dautrevaux [EMAIL PROTECTED] wrote:
Since modifying the next release of libtool won't contribute at all to
fix the problem in already compiled programs, which are the only
programs affected by this problem
I usually still build production code with a libc5 setup, and
Hi!
Speaking for myself as a Debian maintainer (not a libtool maintainer):
Alexandre is angry because we have deliberately chosen not to fully
implement Red Hat's ugly (and effective) ld.so hack, but yet we also
claim that we're ``just following what everybody else is doing,'' and
that none of
On 1 Feb 1999, Gordon Matzigkeit wrote:
In short, we have only three choices, regardless of what happens in
libtool:
1) Implement Red Hat's ugly patch in our libc5 ld.so, and thereby be
bugwards compatible with everybody else's Linux.
2) Find some other way to make -rpath on Debian
On Mon, Feb 01, 1999 at 12:19:48PM -0700, Jason Gunthorpe wrote:
In short, we have only three choices, regardless of what happens in
libtool:
1) Implement Red Hat's ugly patch in our libc5 ld.so, and thereby be
bugwards compatible with everybody else's Linux.
2) Find some other
Ian Lance Taylor [EMAIL PROTECTED] writes:
Date: Sat, 30 Jan 1999 16:52:48 -0700 (MST)
From: Jason Gunthorpe [EMAIL PROTECTED]
That's not what I'd like libtool to do. I agree there is a problem to
be fixed, I just think that libtool is not the only piece of software
Marcus Brinkmann [EMAIL PROTECTED] writes:
On Mon, Feb 01, 1999 at 12:19:48PM -0700, Jason Gunthorpe wrote:
In short, we have only three choices, regardless of what happens in
libtool:
1) Implement Red Hat's ugly patch in our libc5 ld.so, and thereby be
bugwards compatible
On Feb 1, 1999, Jim Pick [EMAIL PROTECTED] wrote:
Marcus Brinkmann [EMAIL PROTECTED] writes:
On Mon, Feb 01, 1999 at 12:19:48PM -0700, Jason Gunthorpe wrote:
to do one of the above, the most sensible is to steal RH's patch so that
we are compatible.
I agree. Option 1 is definitely the
On Jan 30, 1999, Jason Gunthorpe [EMAIL PROTECTED] wrote:
On 30 Jan 1999, Alexandre Oliva wrote:
I agree there is a problem to be fixed, I just think that libtool
is not the only piece of software that may have to be changed to
fix it, because it is not the only piece of software that uses
On Jan 30, 1999, Marcus Brinkmann [EMAIL PROTECTED] wrote:
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.
Just a minor nit: rpaths and sonames are independent of one-another.
Although it is possible to arrange
On 30 Jan 1999, Alexandre Oliva wrote:
libtool is however the only piece of software that we cannot easially
change.
then I said one could just as easily edit the libtool script, and I
have even posted a script that would do that for you.
Ah I missed that script, maybe we should just
Date: Sat, 30 Jan 1999 16:06:04 -0700 (MST)
From: Jason Gunthorpe [EMAIL PROTECTED]
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
Date: Sat, 30 Jan 1999 16:52:48 -0700 (MST)
From: Jason Gunthorpe [EMAIL PROTECTED]
That's not what I'd like libtool to do. I agree there is a problem to
be fixed, I just think that libtool is not the only piece of software
that may have to be changed to fix it, because it is
On Jan 30, 1999, Jason Gunthorpe [EMAIL PROTECTED] 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
On 30 Jan 1999, Alexandre Oliva wrote:
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
Hi, all!
There's been so much traffic on this thread, that I suspect most
people have missed the fact that Ian Lance Taylor has analyzed and
*solved* the problems with interaction between libtool and
libc5-compat shared libraries.
I'm quoting and reposting his message so that it doesn't get lost
Gordon Matzigkeit wrote:
There's been so much traffic on this thread, that I suspect most
people have missed the fact that Ian Lance Taylor has analyzed and
*solved* the problems with interaction between libtool and
libc5-compat shared libraries.
I don't think this adresses the core problem.
Joey Hess wrote:
* Program xfoo is linked with libXaw.so
* -rpath is used so it's hard coded to look for this library in
/usr/X11R6/lib/
* The user of program xfoo wants to use the xaw3d widget set with it instead
of the default libXaw.so. They expect to be able to set LD_PRELOAD to
Alexandre Oliva wrote:
The point is that you've just been asking for libtool not to use
-rpath at all,
Yes, I think this is the correct solution.
but this would only work for people who create .deb or .rpm binary
packages,
You fill this house with lies. It works for anyone putting libraries in
Gordon Matzigkeit writes:
Hi, all!
There's been so much traffic on this thread, that I suspect most
people have missed the fact that Ian Lance Taylor has analyzed and
*solved* the problems with interaction between libtool and
libc5-compat shared libraries.
By, as far as I can tell, breaking
On Sat, Jan 30, 1999 at 10:40:33PM -0600, Gordon Matzigkeit wrote:
There's been so much traffic on this thread, that I suspect most
people have missed the fact that Ian Lance Taylor has analyzed and
*solved* the problems with interaction between libtool and
libc5-compat shared libraries.
Date: Sun, 31 Jan 1999 13:08:51 -0600
From: David Engel [EMAIL PROTECTED]
I am the Debian and upstream maintainer of the libc5 ld.so. Ian's
patch will not be going in.
I think most people understand this, but I should make clear that it's
not my patch. I assume it's from Eric
From: Olaf Weber [EMAIL PROTECTED]
Date: 31 Jan 1999 11:39:23 +0100
Hi, all!
There's been so much traffic on this thread, that I suspect most
people have missed the fact that Ian Lance Taylor has analyzed and
*solved* the problems with interaction between libtool and
Buddha Buck [EMAIL PROTECTED] writes:
does it know that libc5 and libc6 are incompatable versions of the
same library (different sonames), or does it feel that loading two
libraries (libfoo, libc6) is better than loading three (libfoo,
libc5, libc6).
It recognizes libc, libm, and libdl in
On Jan 29, 1999, Buddha Buck [EMAIL PROTECTED] wrote:
[exact description of what I had assumed about the behavior of
ld.so, based on previous postings to the libtool mailing list,
snipped]
This is not how I understand how the ld.so linker works on Linux
systems. My understanding is that it
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.
On Jan 30, 1999, Jason Gunthorpe [EMAIL PROTECTED] wrote:
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
On 30 Jan 1999, Alexandre Oliva wrote:
On Jan 30, 1999, Jason Gunthorpe [EMAIL PROTECTED] wrote:
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
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,
In the thread on -rpath that is currently taking place on the
debian-devel mailing list (quick summary: Debian developers say that
-rpath should -not- be the default on Linux systems; libtool developers
say that -rpath should be the default on all systems), Alexandre Oliva
has repeatedly
35 matches
Mail list logo
