-Original Message-
From: Ian Lance Taylor [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 30, 1999 11:40 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
debian-devel@lists.debian.org; [EMAIL PROTECTED]
Subject: Re: -rpath with libtool and Debian Linux
On Feb 1, 1999, Bernard Dautrevaux [EMAIL PROTECTED] wrote:
In general, it's convenient to store the path in the executable any
time a shared library is installed in a directory which the dynamic
linker does not search by default.
Especially if it is related to the executable. If it's a
use -rpath /usr/lib for their programs.
Just to make it clear, since I don't think this has come up yet,
/usr/lib isn't the only problem -- /usr/X11R6/lib is as well (or was,
at some point; I haven't looked at the upstream XFree86 Imake
configuration recently, but it did use --rpath at one point
On Jan 29, 1999, Jason Gunthorpe [EMAIL PROTECTED] wrote:
Didn't we decide that all of the available alternatives that you have
suggested are not a feasable solution (does this mail help make it clear
why)?
On 29 Jan 1999, Alexandre Oliva wrote:
You may have missed the ugly one I was
On Jan 29, 1999, Hamish Moffatt [EMAIL PROTECTED] wrote:
On Fri, Jan 29, 1999 at 07:11:54AM -0200, Alexandre Oliva wrote:
On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote:
Therefore, we chose to solve that particular problem (the libc5-6
transition) by moving libraries around, knowing
On Jan 29, 1999, Hamish Moffatt [EMAIL PROTECTED] wrote:
On Fri, Jan 29, 1999 at 07:27:28AM -0200, Alexandre Oliva wrote:
Does it? You mean, that hack in ld.so that adds /usr/lib/libc5 to the
library search path in certain circumstances? The hack is incomplete,
you just have to fix it.
Hi,
On Fri, Jan 29, 1999 at 03:41:46PM -0600, Gordon Matzigkeit wrote:
I don't understand this comment. Which trouble with --rpath do
you mean?
AO The exact problem the Debian developers have been complaining
AO about. The more I think about the problem, the more I see that
AO
On Jan 29, 1999, Steve Dunham [EMAIL PROTECTED] wrote:
Maybe we should just agree that libtool is broken, that it won't be
fixed upstream, and just fix the Debian version? This would mean
that we would have to rerun autoconf co when we build packages
Actually, you'd just have to modify the
On Sat, Jan 30, 1999 at 07:46:21PM -0200, Alexandre Oliva wrote:
On Jan 29, 1999, Jason Gunthorpe [EMAIL PROTECTED] wrote:
rpath prevents library searching and thus kills this functionality.
It doesn't prevent library searching, it just takes precedence over
it. If the library is not
Date: Sat, 30 Jan 1999 23:30:43 +0100
From: Marcus Brinkmann [EMAIL PROTECTED]
Why should the application choose to hard code the PATH in the binary?
AFAICS, there is no apparent reason for it. What has the path to do with the
library? I think the only thing that should be hard
On Sat, Jan 30, 1999 at 05:40:24PM -0500, Ian Lance Taylor wrote:
Suppose you have your own set of shared libraries, in your own
directory. Suppose you want to let other people use your programs
linked against your own shared libraries. You can tell everyone who
uses your programs to set
Date: Sat, 30 Jan 1999 23:10:26 +0100
From: Marcus Brinkmann [EMAIL PROTECTED]
* Is there a better way to do a library transition? I think it is very
obvious, that the only correct behaviour is to change the
library/soname of all involeved libraries when doing a transition.
So
On Sat, Jan 30, 1999 at 05:49:39PM -0500, Ian Lance Taylor wrote:
* Is there a better way to do a library transition? I think it is very
obvious, that the only correct behaviour is to change the
library/soname of all involeved libraries when doing a transition.
So we had to move
On Sat, Jan 30, 1999 at 05:49:39PM -0500, Ian Lance Taylor wrote:
Shouldn't there be a way to override rpath? Currently,LD_LIBRARY_PATH does
override rpath, right?
No, LD_LIBRARY_PATH does not override rpath. The rpath is searched
first, and then the LD_LIBRARY_PATH is searched. I
Date: Sat, 30 Jan 1999 23:42:32 +0100
From: Marcus Brinkmann [EMAIL PROTECTED]
In general, it's convenient to store the path in the executable any
time a shared library is installed in a directory which the dynamic
linker does not search by default.
Yes, I should have
On Jan 30, 1999, Ian Lance Taylor [EMAIL PROTECTED] wrote:
In the normal case I think one can assume that the dynamic linker will
search any directory listed in /etc/ld.so.conf, and it would be OK to
omit a -rpath argument for any shared library installed in one of the
directories listed in
Marcus Brinkmann [EMAIL PROTECTED] writes:
On Fri, Jan 29, 1999 at 03:41:46PM -0600, Gordon Matzigkeit wrote:
I don't understand this comment. Which trouble with --rpath do
you mean?
AO The exact problem the Debian developers have been complaining
AO about. The more I think
On Jan 30, 1999, Manish Singh [EMAIL PROTECTED] wrote:
No, LD_LIBRARY_PATH does not override rpath. The rpath is searched
first, and then the LD_LIBRARY_PATH is searched. I think you may have
agreed with that later in your message.
This is another irksome thing about libtool and -rpath.
On Jan 27, 1999, Marcus Brinkmann [EMAIL PROTECTED] wrote:
On Wed, Jan 27, 1999 at 08:22:09PM -0200, Alexandre Oliva wrote:
3) I don't want to regret having introduced a flag that caused as much
or more trouble than -rpath; and
I don't understand this comment. Which trouble with --rpath do
On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote:
1) it would be hard to make it behave correctly in a portable way (and
libtool would be useless if it were not for being portable);
Special case-it for linux, if you will. Libtool has plenty of special
cases as it is.
Not in the
On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote:
Therefore, we chose to solve that particular problem (the libc5-6
transition) by moving libraries around, knowing that our linker was up to
the job.
It is now clear that it is not. :-(
rpath is broken. You said as much yourself. rpath
On Jan 27, 1999, Ulrich Drepper [EMAIL PROTECTED] wrote:
Jules Bean [EMAIL PROTECTED] writes:
rpath is broken. You said as much yourself. rpath is broken because it
*overrides* all other sorts of library searching.
I think people here do not know about $ORIGIN. This allows to define
On Jan 27, 1999, Jason Gunthorpe [EMAIL PROTECTED] wrote:
Actually you want to know why I remember this? I used libtool a while back
and I installed a copy of my program in /usr/bin and /usr/lib and wanted
to us a new local copy of my libtool program. Of course libtool had used
-rpath to make
On Jan 28, 1999, Bernard Dautrevaux [EMAIL PROTECTED] wrote:
You say the contract is I want to find THERE the lib that does THIS.x
and THAT.x; I think (and that's at least true for Linux) the contract
the compiler and linker has signed was twofold; it says:
1) I will give you the library
Alexandre Oliva wrote:
ld.so is trying to outsmart everybody, but it is not smart enough to
do it. When you moved libc5-compatible libraries from /usr/lib to
/usr/lib/libc5, you established a rule that, if any program was linked
with libc5, it should look for libraries in /usr/lib/libc5
On Jan 29, 1999, Richard Braakman [EMAIL PROTECTED] wrote:
Alexandre Oliva wrote:
ld.so is trying to outsmart everybody, but it is not smart enough to
do it. When you moved libc5-compatible libraries from /usr/lib to
/usr/lib/libc5, you established a rule that, if any program was linked
On Fri, Jan 29, 1999 at 07:11:54AM -0200, Alexandre Oliva wrote:
On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote:
Therefore, we chose to solve that particular problem (the libc5-6
transition) by moving libraries around, knowing that our linker was up to
the job.
It is now clear
On Fri, Jan 29, 1999 at 07:27:28AM -0200, Alexandre Oliva wrote:
Does it? You mean, that hack in ld.so that adds /usr/lib/libc5 to the
library search path in certain circumstances? The hack is incomplete,
you just have to fix it.
Have you checked our ld.so source? The only mentioned of
Previously Alexandre Oliva wrote:
Good analogy. What's happening here is that Debian is placing the red
lable on the cold water tap. I.e., they're replacing a library with
an incompatible version of it, and getting in trouble because some
programs are now getting cold water where they
On 29 Jan 1999, Alexandre Oliva wrote:
Didn't we decide that all of the available alternatives that you have
suggested are not a feasable solution (does this mail help make it clear
why)?
You may have missed the ugly one I was referring to, that I suggested
in the very beginning of
Hi!
[Creaaak... Gordon pops out of the grave reserved for former
libtool maintainers to make some comments.]
Alexandre Oliva writes:
I don't understand this comment. Which trouble with --rpath do
you mean?
AO The exact problem the Debian developers have been complaining
AO about.
Hamish Moffatt [EMAIL PROTECTED] writes:
On Fri, Jan 29, 1999 at 07:27:28AM -0200, Alexandre Oliva wrote:
Does it? You mean, that hack in ld.so that adds /usr/lib/libc5 to the
library search path in certain circumstances? The hack is incomplete,
you just have to fix it.
Have you
At 15:41 -0600 1999-01-29, Gordon Matzigkeit wrote:
The best solution I can come up with is to *always* change a library's
soname when its dependencies change. I believe it was Joel Klecker
who mentioned something about `libapi' patches for egcs that were
supposed to implement this automatically.
On 27 Jan 1999, Alexandre Oliva wrote:
You know, I seem to remember that there is another rather unpleasent
side-effect of rpath - it basically completely disables library searching
and thus disables LD_LIBRARY_PATH, once you have used rpath it is not easy
for a user replace that library
Alexandre == Alexandre Oliva [EMAIL PROTECTED] writes:
Ben With Debian and Red Hat, it's totally the opposite. Moving
Ben libraries around is what leads to upgrades being possible.
Alexandre Then why do you find so much trouble with it?
Because of -rpath. :)
That's the only reason
-Message d'origine-
De: Ulrich Drepper [SMTP:[EMAIL PROTECTED]
Date: jeudi 28 janvier 1999 00:54
À:Jules Bean
Cc: Alexandre Oliva; Debian Developers; [EMAIL PROTECTED]
Objet:Re: -rpath with libtool and Debian Linux
Jules Bean [EMAIL PROTECTED] writes:
rpath
-Message d'origine-
De: Alexandre Oliva [SMTP:[EMAIL PROTECTED]
Date: mercredi 27 janvier 1999 20:53
À:J.H.M. Dassen
Cc: debian-devel@lists.debian.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Objet:Re: -rpath with libtool and Debian Linux
On Jan 27
-Message d'origine-
De: Alexandre Oliva [SMTP:[EMAIL PROTECTED]
Date: mercredi 27 janvier 1999 22:23
À:Jules Bean
Cc: J.H.M. Dassen; debian-devel@lists.debian.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Objet:Re: -rpath with libtool and Debian Linux
I'm bringing this conversation (with permission) to
debian-devel@lists.debian.org because my knowledge of how -rpath works
is limited.
To recap, for the Debian folks:
libtool, a tool for creating libraries and linking programs with those
libraries on multiple platforms, forces all programs it
On Jan 27, 1999, Ben Gertzfield [EMAIL PROTECTED] wrote:
This is bad for Debian, because in all binary packaging systems,
shared libraries can and will be moved around from time to time, as
policy and major upgrades (like libc5 - libc6) mandate.
You might have included my suggestion to
On Wed, Jan 27, 1999 at 17:07:30 -0200, Alexandre Oliva wrote:
You might have included my suggestion to prevent having to move libraries
in the first place: creating a libc6-specific directory right now, instead
of installing libraries in /usr/lib and having to move them into another
directory
Alexandre == Alexandre Oliva [EMAIL PROTECTED] writes:
Alexandre You might have included my suggestion to prevent having
Alexandre to move libraries in the first place: creating a
Alexandre libc6-specific directory right now, instead of
Alexandre installing libraries in /usr/lib
On Jan 27, 1999, J.H.M. Dassen [EMAIL PROTECTED] wrote:
On Wed, Jan 27, 1999 at 17:07:30 -0200, Alexandre Oliva wrote:
You might have included my suggestion to prevent having to move libraries
in the first place: creating a libc6-specific directory right now, instead
of installing libraries
On Jan 27, 1999, Ben Gertzfield [EMAIL PROTECTED] wrote:
I've never understood what the .la scripts are for.
They contain inter-library dependency information, the location and
the name of the actual library, and any additional run-time paths
needed for the library dependencies. libtool (1.2d)
On 27 Jan 1999, Alexandre Oliva wrote:
Having libtool default to -rpath is what's causing problems.
This is IMHO completely backwards :-)
When a program is linked with a shared library, a contract is
established between them stating that the library (or any newer but
compatible version
On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote:
On 27 Jan 1999, Alexandre Oliva wrote:
Having libtool default to -rpath is what's causing problems.
This is IMHO completely backwards :-)
When a program is linked with a shared library, a contract is
established [...] If you move the
On 27 Jan 1999, Alexandre Oliva wrote:
The contract simply states that the library will be found. Which
library is used can be determined by the linker.
Except that, if you replace the library with an incompatible one, you
*are* breaking the contract.
We don't replace libraries with
On 27 Jan 1999, Alexandre Oliva wrote:
Having libtool default to -rpath is what's causing problems.
This is IMHO completely backwards :-)
You know, I seem to remember that there is another rather unpleasent
side-effect of rpath - it basically completely disables library searching
and thus
On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote:
On 27 Jan 1999, Alexandre Oliva wrote:
Except that, if you replace the library with an incompatible one, you
*are* breaking the contract.
We don't replace libraries with incompatible ones.
Oh yes, you are.
We bring in new libraries,
On 27 Jan 1999, Alexandre Oliva wrote:
If you do want to be able to freely move libraries around, -rpath must
be forbidden. If -rpath is available for users, you can't move
libraries around and expect things to work.
There are lots of things which users can do which might appear to work,
On Jan 27, 1999, Jason Gunthorpe [EMAIL PROTECTED] wrote:
On 27 Jan 1999, Alexandre Oliva wrote:
Having libtool default to -rpath is what's causing problems.
This is IMHO completely backwards :-)
You know, I seem to remember that there is another rather unpleasent
side-effect of rpath -
On 27 Jan 1999, Alexandre Oliva wrote:
In normal cases the dymanic linker would figure this out one way or
another with rpath this functionality is disabled as it overrides
the library versioning scheme.
The linux dynamic linker will resolve things in some magical way based on
the
On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote:
On 27 Jan 1999, Alexandre Oliva wrote:
Can you tell -rpath to store the rpath for libmycustomthing.so and
not for libc.so?
No, but, on some systems (for example, GNU/Linux), it is possible to
hard-code the full pathname of
On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote:
Since you do support -rpath in your system, you should probably extend
your dynamic linker to work in this case too, or risk taking the blame
for silently breaking applications, if the poor user ever understands
what happened to his
Jason Gunthorpe wrote:
On 27 Jan 1999, Alexandre Oliva wrote:
Having libtool default to -rpath is what's causing problems.
This is IMHO completely backwards :-)
You know, I seem to remember that there is another rather unpleasent
side-effect of rpath - it basically completely
On Wed, Jan 27, 1999 at 08:22:09PM -0200, Alexandre Oliva wrote:
I don't think that libtool is the right vehicle for you to evangelise your
dislike of packaging systems and the FHS.
But debian-devel is probably a good place to talk about these ideas.
Please start another thread under a
Alexandre Oliva wrote:
More than that (and it was my fault to have failed to mention that
before): libtool will hard-code the installation directory of the
library into the `libdir' variable of the .la script it installs.
Therefore, if one moves the library then tries to link with the .la
On 27 Jan 1999, Alexandre Oliva wrote:
On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote:
On 27 Jan 1999, Alexandre Oliva wrote:
[watch indenting carefully : I wrote this next bit, of course]
In general, it is not useful to have multiple versions of the same
package.
You're
On 27 Jan 1999, Alexandre Oliva wrote:
On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote:
Since you do support -rpath in your system, you should probably extend
your dynamic linker to work in this case too, or risk taking the blame
for silently breaking applications, if the poor user
Jules Bean [EMAIL PROTECTED] writes:
rpath is broken. You said as much yourself. rpath is broken because it
*overrides* all other sorts of library searching.
I think people here do not know about $ORIGIN. This allows to define
relative rpaths. E.g., a package with a program foo and a
60 matches
Mail list logo
