[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

-rpath with libtool and Debian Linux



I'm bringing this conversation (with permission) to
debian-devel@lists.debian.org because my knowledge of how -rpath works
is limited.

To recap, for the Debian folks:

libtool, a tool for creating libraries and linking programs with those
libraries on multiple platforms, forces all programs it links to be
linked with the -rpath option, which hard-codes the path to the
library being linked with into the binary.

This is bad for Debian, because in all binary packaging systems,
shared libraries can and will be moved around from time to time, as
policy and major upgrades (like libc5 -> libc6) mandate.

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, or if your Unix has
no support for library search paths via environment variables like
Linux's LD_LIBRARY_PATH.

Basically, I have been asking Alexandre if it's possible to add a
--no-rpath option to libtool when calling it to tell it to not use
-rpath when linking binaries, but he refused, saying he'd have to port
that to 'hundreds of platforms'.

Can someone with more knowledge of -rpath and libtool than I explain
why Debian policy mandates avoiding -rpath?

Thanks,

Ben

-- 
Brought to you by the letters C and O and the number 14.
"Porcoga daisuki!"
Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.
------- Start of forwarded message -------
To: Ben Gertzfield <che@debian.org>
Cc: Manish Singh <yosh@gimp.org>, bug-libtool@gnu.org,
        James Troup <james@nocrew.org>
Subject: Re: [gimp-devel] gimp1.1 rpath hell
References: <874spgxobd.fsf@nocrew.org> <ytt679vkpoz.fsf@gilgamesh.cse.ucsc.edu> <19990126173541.B12800@yosh.gimp.org> <or90epqxn5.fsf@araguaia.dcc.unicamp.br> <ytt4spd31af.fsf@gilgamesh.cse.ucsc.edu> <ord841ph1k.fsf@araguaia.dcc.unicamp.br> <yttvhht1kxc.fsf@gilgamesh.cse.ucsc.edu>
From: Alexandre Oliva <oliva@dcc.unicamp.br>
Date: 27 Jan 1999 01:16:59 -0200
Message-ID: <or4spdpfpw.fsf@araguaia.dcc.unicamp.br>
Mime-Version: 1.0

On Jan 27, 1999, Ben Gertzfield <che@debian.org> wrote:

Alexandre> Or just fix ld.so so that, if a program or library
Alexandre> depends on libc.so.5, it shouldn't even try to use
Alexandre> libc.so.6, and vice-versa.

> If we move the libraries, any program that is compiled with -rpath
> WILL NO LONGER WORK. Period.

You shouldn't move shared libraries.  Period :-)

If the particular version of libX11.so was linked with depends on
libc.so.5, ld.so should use it.  I don't see any need for a separate
directory for libraries, if library versioning would work correctly.

> This has happened before with Debian, as emacs was compiled with
> -rpath /usr/X11R6/lib to force the X libraries to be stored there.

If libraries are not found in the -rpath, they should be searched in
the default search directories.  Aren't they?

-- 
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

------- End of forwarded message -------


Reply to: