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