Re: -rpath with libtool and Debian Linux
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.
> > 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.
>
> > 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.)
>
> Ian
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: