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
> -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 lib
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 -r
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.
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
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 na
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.
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 m
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: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 s
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 co
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
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
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 s
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 fi
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 ar
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
> 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
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.
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
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
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 beginni
TECTED]
> Subject: Re: -rpath with libtool and Debian Linux
>
>
> 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
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 exp
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 "
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 no
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 lin
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 f
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
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
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 def
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. rp
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 i
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 "
> -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: -rpa
> -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 wit
> -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 Be
> "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
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
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 li
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
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.
>
>
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 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
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 com
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 hi
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 libmycustomt
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
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
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 wor
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 libra
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 th
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
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
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 ve
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.2
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 l
> "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
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
> direct
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 p
60 matches
Mail list logo
