Re: -rpath with libtool and Debian Linux
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 see that
> AO> the problem they're facing is an incomplete hack of ld.so, in
> AO> that it modifies the library search path under certain
> AO> circumstances, but not in all circumstances that would need it.
>
> Exactly.
Mmh. I think I see the point now, and I have to agree.
So, the problem we are facing is twofold:
* How can Debian hack around the rpath problem, so user can use third party
software which is libc5+rpath.
* 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 move either from libfoo.2 to libfoog.2, libfoo.libc6.2,
libc6/libfoo.2 or whatever, until a new library with a new, incompatible,
soname is released. Changing the name does not look correct, so we had
to change soname or path.
I am sorry if this sounds quite confusing, but I hope you get the idea
(Gordon, this is exactly what we discussed on the Hurd list, right?).
Fortunately, libc6 will use symbol versioning, so we will not experience
problems at this scale again (hopefully).
Furthermore, it would be great if upstream author, compiler and installer
could all influence the linking conditions (rpath or not etc), which seems
to be a good goal. This could fix our problem, too, but only as a hack. The
theoretical solution is outlined above.
There is still the issue of xaw wrappers, can you please comment on this?
Shouldn't there be a way to override rpath? Currently,LD_LIBRARY_PATH does
override rpath, right? But then, if I want to link a program which was
compiled for xaw with xaw3d, to get a better look+feel, I would need a way
to override the rpath inside the binary. Maybe another environment variable
is needed for this, or should the priority changed?
Because, I really think the sysadmin/user should always have the last word
on this issue. Currently, rpath overrides everything, which is set by the
distributor of the binary.
> >> This means, the package can provide a default, which can be
> >> overridden at compilation time. Finally, the installer can
> >> override both.
I should add here that ideally, a user/sysadmin should always be able to
override all three.
> AO> That's exactly what I'm looking for. But I wouldn't like to
> AO> install a quick hack now that would later reveal to be a step in
> AO> the wrong direction. That's why I'm being so conservative about
> AO> all this issue.
>
> For the record, Alexandre's conservativeness is well-justified.
I still don't see if libtools default, rpath, is correct, but I see now what
Debian did wrong. I also see that if Debian would have done it correctly,
the use of rpath would be a non-issue.
> The best solution I can come up with is to *always* change a library's
> soname when its dependencies change.
Ah, here you say it what I cludged together above with my limited
understanding of the issues :)
Thanks,
Marcus
--
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: