Re: -rpath with libtool and Debian Linux
On 27 Jan 1999, Alexandre Oliva wrote:
> > You know, I seem to remember that there is another rather unpleasent
> > side-effect of rpath - it basically completely disables library searching
> > and thus disables LD_LIBRARY_PATH, once you have used rpath it is not easy
> > for a user replace that library (for whatever reason) and I find that
> > highly annoying.
>
> Well, he could always move the library elsewhere and put whatever he
> wants in its place... Some people might be consider it a bug in the
> dynamic linker, that could look at LD_LIBRARY_PATH before -rpath. I
> think -rpath really means it, so I consider the behavior correct
> (albeit a bit inconvenient for us, maintainers of libtool)
Actually you want to know why I remember this? I used libtool a while back
and I installed a copy of my program in /usr/bin and /usr/lib and wanted
to us a new local copy of my libtool program. Of course libtool had used
-rpath to make sure that my local binary used /usr/lib (as it was intended
to be installed there someday) and then used LD_LIBRARY_PATH in the
wrapper script to try to override this. Needless to say it did not work
and it took me a bit of figuring to determine why my changes had no
effect. Even in an all libtool environment rpath causes pain.
Actually you might have something there with the search order. What if the
linker were to examine it's library list before examining rpath, rpath
would be like a compiled in default search path instead of a compiled in
search path override. The ld-linux people probably would not go for that
though.
Incidently from what I've read I think that description of rpath more
closely matches what you want to use it for than does it's current
behavior.
> > The linux dynamic linker will resolve things in some magical way based on
> > the library dependencies and the program dependencies to locate the proper
> > library in many cases - rpath does cripples, not enhances, this function.
>
> 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.
Well then you change the meaning of rpath, if you accept rpath means 'use
this library not matter what the consequences' then it is arguable the
user should expect that from rpath.
> This is a good point. But since all of you face this same problem,
> and all of you use the same major versions of libc, you can probably
> agree on a solution that would benefit you all. Or arrange, via
Lol! There has been little luck in that area, the only way to do it would
really be to convince all the upstream maintianers to do that and then
force those changes on the distributions. In any event as we agree below
this is not an adaquate solution.
> inter-package dependencies, that required libraries are installed in
> the proper places.
No, we are talking about 3rd party binary applications such as netscape -
arguably they are a compelling reason why we use the scheme we do.
> It seems to me that the main problem has to do with library
> versioning. Even though the existing library versioning mechanisms
> are great to describe the evolution of the API offerred by a library,
> they by no means describe the dependencies of a library, so we end up
> with libraries that have the same version numbers but that are not
> compatible at all.
Bingo. We have a dynamic linker that can complete the second half of the
puzzle if all available major versions of a library are in the search
path, it will pick the one with the matching dependencies, we as a
distribution vendor take steps to make sure that any compatibility
libraries remain within the linkers search path.
> What we all are desperately looking for is a mechanism to allow the
> dynamic loader to pick the right version of a shared library out of a
> set of multiple builds of the same version of a library, the main
> difference between them being their dependencies.
I belive we already have this capablility - the only problem is that rpath
disables it. If rpath did not break the normal library searching
mechanisms then nobody would care that libtool uses it. [See above]
> If there is more than one dependency, there is no way to ensure that
> the major version number is increased whenever it has to be. Or I
> just can't find out how :-)
No, you will never be able to work this out because you have to get the
upstream author to do it, assume for instance that we changed our xlib6
soname to be libX11.so.6-C6-ICE6 then anything that is linked on our
system will not work on a redhat one unless they did the same and then
people who compile out of the tar ball would be in trouble and so on.
Permuting the soname is not a good enough solution because it cannot be
applied universally and consistently.
> > We must be able to turn it off for libraries used on our system!
>
> I have already told you one (ugly) way to do it, but I still don't
> think it is a good idea in the general case.
Didn't we decide that all of the available alternatives that you have
suggested are not a feasable solution (does this mail help make it clear
why)?
Now correct me if I am wrong but the story goes like this:
- rpath is good because it allows a binary to have a shared library
in a non-standard place without requiring the user to use
LD_LIBRARYPATH or the sysadmin to add that place to the search
path
- rpath is bad because it disables LD_LIBRARYPATH
- rpath is bad because it disables the linkers automatic versioning
mechanism
- rpath is bad because it prevents you from moving shared libraries
around freely.
Jason
Reply to: