RE: -rpath with libtool and Debian Linux
> -----Message d'origine-----
> De: Alexandre Oliva [SMTP:oliva@dcc.unicamp.br]
> Date: mercredi 27 janvier 1999 20:53
> À: J.H.M. Dassen
> Cc: debian-devel@lists.debian.org; yosh@gimp.org;
> bug-libtool@gnu.org; libtool@packages.debian.org
> Objet: 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.
>
You mark a point here: everything is about a contract passed by you,
using the compiler, to the system on which you install. The problem is
with the exact contract passed, and interpretation of this contract.
You say the contract is "I want to find THERE the lib that does THIS.x
and THAT.x"; I think (and that's at least true for Linux) the contract
the compiler and linker has signed was twofold; it says:
1) "I will give you the library that makes THIS.x and THAT.x"
2) "The prefered library I want you to use to obtain THIS and THAT
is there and makes THIS.x and THAT.x"
Now you trick it with -rpath in finding both the ".x" and THERE and all
the problem comes from there...
An analogy: When I wand to get hot water in restrooms, I just look at
the tap, and turn the red one; I do not INSIST on opening the left one,
risking to get cold water...
> > 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?
>
Moving the library was just fulfilling the 2nd part of the contract:
"You will find here the prefered library to use for THIS and THAT".
> > 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.
>
Under Linux at least the incompatibilities we are talking here ARE
managed by the dynamic linker, IFF we do not trick it saying him (using
-rpath) "Do not be smart, just load the library from there". YOU are
breaking the Linux contract...
It's possible the way you are using -rpath correspond to the "contract"
of some OSes, but surely not LINUX :-(; and if there is different
contracts to be adhered to depending on the OS, it seems that exaactly
why we use autoconf/automake/libtool: allow us NOT to bother about OS
diferences but rather be able to ask libtool: "Do what teh OS expect you
to do to fulfill its contracts"
So my opinion, at least on Linux, would be not to use -rpath, except if
we need to access shared libraries that WE install together with the
executables; and then install it in some package-dependant directory
where we have no risk to get ANY other lib, pass ONLY this dir to the
exec using -rpath, and then all should be OK.
Now for the one that want to compile and install a set of interdependant
packages in it's home directory on some OS where he is not able to pass
some kind of an LD_LIBRARY_PATH to the exec, then it may use some option
to each compiles asking that -rpath be passed for all links, and warn
him he should not try to distribute or move the resultant installed
packages, and may need to reinstall them if changing its system
configuration.
Regards,
Bernard
> >> > 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
>
------------------------------------------------------------------------
------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: dautrevaux@microprocess.com
b.dautrevaux@usa.net
------------------------------------------------------------------------
------
Reply to: