Re: -rpath with libtool and Debian Linux
Date: Tue, 2 Feb 1999 18:05:45 -0600
From: John Goerzen <jgoerzen@complete.org>
On Tue, Feb 02, 1999 at 06:47:26PM -0500, Ian Lance Taylor wrote:
> 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.
>
> But if that person happened to be building on a libc5 system with the
> hardcoded path, then Debian already broke his program. I agree that
No, HE broke his program. When you use -rpath, you are presumably aware of
the consequences of your actions, both beneficial and harmful. If you use
it, you have to be aware that this can happen.
This argument would be more convincing if -rpath weren't required on
most Unix systems. Most Unixes do not have the complex ldconfig
mechanisms provided by Linux. Therefore, it is natural for people
writing cross-platform tools to add a -rpath argument to find, e.g.,
the X libraries.
-rpath is not some weird bizarro option. It's quite commonly used by
people who understand the difference between the program linker search
path and the dynamic linker search path.
-rpath works reasonably in the presence of upgrades, provided the
upgrade does not move any shared libraries. This is typical on other
Unix systems. Linux had a special one-time problem in the switch from
libc5 to glibc. Unfortunately, that switch was not handled as cleanly
as it could have been.
> > 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.
>
> Those are different versions of the library. They have different
> requirements. From the perspective of the dynamic linker, they can
> not be considered to be the same version.
That's what I was thinking (hence my confusion about which versioning
mechanism he's talking about). He was saying that we replaced a library
with a different and incompatible one, but of the same version.
I don't see that in the quoted paragraph, although the appropriate
quote may have been dropped somewhere. He is referring to the
versioning mechanism, which is the soname. When the library changed
in an incompatible fashion, the soname should have changed.
Unfortunately, that didn't happen.
> > 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.
>
> I disagree. If the OS is gong to move the library, it is responsible
> for making sure that old programs linked using -rpath continue to
> work, one way or another. You are effectively saying that -rpath is
> prohibited, which I do not think is reasonable.
No! -rpath is saying that it wants the program to IGNORE what the OS says
about where the library is. We don't care about programs that use -rpath;
they presumably know what they're doing. The program is, if our
distribution has programs compiled with -rpath, we can have trouble. (I
would say that almost no user would do that if it weren't the default.)
I disagree. You should care about programs which use -rpath, and you
should strive to make them continue to work when possible.
In any case, I think everybody agrees that programs linked using
-rpath on a glibc system will consistently work on all foreseeable
future glibc systems.
Ian
Reply to: