Re: -rpath with libtool and Debian Linux
On Wed, Jan 27, 1999 at 05:53:12PM -0200, Alexandre Oliva wrote:
> > I'm sorry, but this is IMHO completely backwards. On Linux systems, there is
> > nothing wrong with moving libraries around as the need arises.
>
> Except that you risk replacing a library with an incompatible one.
> That's what has caused you so much trouble. If, instead of moving the
> X11 libraries to another dir and creating new, incompatible versions
> under the same pathname, you had created new versions in other
> directories, no unexpected crashes would have occurred.
OK, let's assume for a moment that we cripple Debian by ignoring the FHS in
this instance. Not all Linux distributions will make this choice. So
somebody on some other distribution compiles things with the pathname
hard-coded in. On his system, it is /usr/X11R6/lib for libraries. But his
program will not work on Debian, because we would have listened to you and
moved our current libraries to a nonstandard location.
If people use -rpath like you reccommend, the consequences are that
virtually all commercial Linux apps would be unusable on Debian. That
virtually all Linux binaries would be unusable on Debian.
I frankly am not going to accept this, and I fail to see why you think that
we ought to cripple our distribution so badly simply because you are
unwilling to add a simple command-line option to libtool to fix this
brokenness.
> and the program will be able to find the library at that point. If
> you move the library and replace it with an incompatible one, you're
> breaking the contract and the versioning mechanism, so you can't blame
> the program for crashing, nor the tool that created the program.
You're missing the point (I think; to which versioning mechanism are you
referring?). It's the same version of the library, designed to be linked
with different versions of other libraries.
We can have libncurses3.4 designed to be linked with libc5 or one for libc6.
> > The X example also shows that the problem isn't limited to /usr/lib either.
> > What's next? /usr/local/lib/libc6 ?
>
> Maybe some library versioning mechanism that allows incompatible
> changes to be marked as such. Maybe an environment variable or some
Ahh, so first you say that we must not take advantage of our unique
features, and now you suggest we add more? Will you condemn us for adding
these features now?
> You see the regular case as the one you use the most. I see it as the
> one I use the most. I don't install any packages in /usr or
> /usr/local because I find it *horrible* to have a huge /usr/local/bin
> without any clear separation between packages. It's a pity that the
> GNU/Linux distributions don't care about clearly separating packages
> from one another...
Five points about that:
#1. Your comments show a fundamental lack of understanding about filesystem
layout in Unix, the FSSTND, and the FHS.
#2. Debian does not install packages in /usr/local/bin.
#3. Debian does not install all binaries in /usr/bin.
#4. Ever heard of 'which'? 'locate'?
#5. You can easily ask a Debian system for information about which
files a package provides, or which package provides a given file.
> Because you break a contract every time you remove a library from the
> place in which it used to live.
The 'contract' never should have cared about its location in the first
place. The OS, through mechanisms like /etc/ld.so.conf, HAS THE RIGHT to
move it. By assuming that it does not, YOU are breaking that contract.
Reply to: