Re: -rpath with libtool and Debian Linux
On Jan 27, 1999, Jason Gunthorpe <jgg@ualberta.ca> wrote:
> On 27 Jan 1999, Alexandre Oliva wrote:
>> > Having libtool default to -rpath is what's causing problems.
>>
>> This is IMHO completely backwards :-)
> 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)
>> See? You replaced one library with an incompatible one without
>> modifying its version number to mark it as incompatible. Isn't this
>> breaking the contract? How could you expect it to work?
> Not exactly, the x libraries are fully compatible
except that they don't work with programs or libraries that had been
compiled with the old version. When I talk of compatibility, I'm
talking about full binary compatibility, not just apparent
compatibility.
> In normal cases the dymanic linker would figure this out one way or
> another with rpath this functionality is disabled as it overrides
> the library versioning scheme.
> 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.
> On another note, you have suggested that we use /usr/lib/libc6 and other
> things to isolate libraries that have been recompiled with updated
> dependencies - the trouble with this is that all the distributions and all
> the distributers would have to agree on a scheme for this - otherwise a
> 'debian' binary would not function on a RH system because they used a
> different scheme and their rpaths would be incompatibly different.
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
inter-package dependencies, that required libraries are installed in
the proper places.
> Furthermore this idea of a /usr/lib/libc6 becomes entirely
> unmanageable when we start having soname changes for things like
> libgtk - we will have the -same- problem with all the millions of
> libs that link with libgtk as we did with libc6!
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.
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.
Using the version number of a dependency to modify the version number
of the dependent library, in order to ensure that incompatibilities
are automatically handled, seems perfect, except that it will only
work when there is only one dependency. :-(
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 :-)
Anyway, I strongly believe that being able to tell libtool not to use
-rpath and to freely move libraries around will only give you more
trouble to worry about in the future.
> 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.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
Reply to: