Re: -rpath with libtool and Debian Linux
On Jan 27, 1999, "J.H.M. Dassen" <jdassen@wi.leidenuniv.nl> wrote:
> On Wed, Jan 27, 1999 at 17:07:30 -0200, Alexandre Oliva wrote:
>> You might have included my suggestion to prevent having to move libraries
>> in the first place: creating a libc6-specific directory right now, instead
>> of installing libraries in /usr/lib and having to move them into another
>> directory when libc7 should be released.
> I'm sorry, but this is IMHO completely backwards. On Linux systems, there is
> nothing wrong with moving libraries around as the need arises.
Except that you risk replacing a library with an incompatible one.
That's what has caused you so much trouble. If, instead of moving the
X11 libraries to another dir and creating new, incompatible versions
under the same pathname, you had created new versions in other
directories, no unexpected crashes would have occurred.
> Having libtool default to -rpath is what's causing problems.
This is IMHO completely backwards :-)
When a program is linked with a shared library, a contract is
established between them stating that the library (or any newer but
compatible version thereof, on systems that support library
versioning) will supply the symbols that the program resolved from it,
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.
> I've seen one too many instances of "<foo> crashes on Debian" that turned
> out to be "<foo> is a libc5 binary with an RPATH of /usr/X11R6/lib" which on
> any reasonably up to date Debian system contains libc6 X libraries.
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?
> The X example also shows that the problem isn't limited to /usr/lib either.
> What's next? /usr/local/lib/libc6 ?
Maybe some library versioning mechanism that allows incompatible
changes to be marked as such. Maybe an environment variable or some
file in /etc containing a number that will be added to the major
version number of any library libtool creates, so that they will be
marked as incompatible.
>> > However, Alexandre Oliva <oliva@dcc.unicamp.br> brings up an important
>> > point: -rpath is necessary if one is installing libraries and binaries
>> > linked to those libraries in one's home directory,
> That is a special case. The default should be sane for regular cases.
You see the regular case as the one you use the most. I see it as the
one I use the most. I don't install any packages in /usr or
/usr/local because I find it *horrible* to have a huge /usr/local/bin
without any clear separation between packages. It's a pity that the
GNU/Linux distributions don't care about clearly separating packages
from one another...
>> > or if your Unix has no support for library search paths via environment
>> > variables like Linux's LD_LIBRARY_PATH.
> While I appreciate concerns about supporting less fortunate operating
> environments, I don't think their existence should hold us back from doing
> the right thing on Linux.
For which definition of the right thing? :-)
>> In general, I feel that moving libraries around is a very bad idea,
>> because it will lead to failure most of the times, and that's why I don't
>> feel libtool should help people doing that.
> I see no reason why moving libraries around is a bad idea. I see defaulting
> to -rpath as a bad idea, which breaks moving libraries around.
Because you break a contract every time you remove a library from the
place in which it used to live.
--
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: