Re: -rpath with libtool and Debian Linux
On 27 Jan 1999, Alexandre Oliva wrote:
> On Jan 27, 1999, Jules Bean <jmlb2@hermes.cam.ac.uk> 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 program.
>
> > Note that 'we' (Debian) write neither the kernel, nor the dynamic linker.
>
> Sorry, I had assumed you had hacked the dynamic linker in order to
> support the /libc5 compatibility libraries.
Absolutely not.
This is one of my main points, in fact.
Our dynamic linker is already very good at solving versioning problems.
It doesn't need us to guarantee the locations of libraries to work - it
can get it all correct anyway.
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.
You are now saying that libtool, by giving no way of avoiding rpath, will
not support this scheme.
>
> > You have previously objected to a proposed solution on the grounds that
> > 'you want libtool to work on all systems'. It seems to me that if you
> > want to make libtool work on Linux, you should find a way of disabling
> > rpath, since rpath is broken on Linux.
>
> rpath is not broken, it just won't let one replace a library (meaning
> moving a library to another directory and installing a new library in
> its place) with one that appears to be compatible, according to the
> version numbers, but is not. That's the root of the problem, and
> that's why you want so much libtool not to use -rpath.
>
rpath is broken. You said as much yourself. rpath is broken because it
*overrides* all other sorts of library searching.
For all I know, there may be a design justification for this. My
understanding of rpath was that it was an 'option of last resort' when you
couldn't make it work any other way (and hence, the overriding of all
other search options is justified).
However, using rpath as default is bad for our setup. Since you think it
is right to use rpath as default, I therefore claim it is broken.
> I feel we're not going to make progress in this discussion unless
> someone comes up with a bright idea about how to allow the user to
> select when/how to hardcode rpaths or not. In the beginning of this
> discussion, Thomas Tanner suggested that -rpath could be dropped if it
> would specify a standard library search directory.
Easy.
Allow libtool to be run with the option
libtool --no-rpath.
This would then be run in all debian-maintained versions of
libtoolized packages, and they'd work.
Furthermore, when talking to software developers, I'd recommend they use
this option by default, disabling it with a
./configure --use-libtool-rpath
if the user really needs the functionality.
> > However, our dynamic linker *does* understand the problem. And it *does*
> > have a solution to it. And -rpath turns it off. So we cannot afford to
> > use -rpath.
>
> As I have already pointed out, the solution is not complete, otherwise
> you'd not be observing any problem.
What do you mean the solution is not complete?
It works. It works well.
People developing only for linux, and not using libtool, wouldn't even
*think* of using rpath since it is a) unnecessary and b) a bad thing.
However, people don't develop only for linux (this is a very good thing).
And because various OSes have wildly different rules for dynamic
libraries, libtool was born to help developers keep their makefiles sane.
And libtool is now deciding not to support the linux model.
Jules
/----------------+-------------------------------+---------------------\
| Jelibean aka | jules@jellybean.co.uk | 6 Evelyn Rd |
| Jules aka | jules@debian.org | Richmond, Surrey |
| Julian Bean | jmlb2@hermes.cam.ac.uk | TW9 2TF *UK* |
+----------------+-------------------------------+---------------------+
| War doesn't demonstrate who's right... just who's left. |
| When privacy is outlawed... only the outlaws have privacy. |
\----------------------------------------------------------------------/
Reply to: