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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Cc: Manish Singh <[EMAIL PROTECTED]>, [EMAIL PROTECTED], James Troup <[EMAIL PROTECTED]> Subject: Re: [gimp-devel] gimp1.1 rpath hell References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> From: Alexandre Oliva <[EMAIL PROTECTED]> Date: 27 Jan 1999 01:16:59 -0200 Message-ID: <[EMAIL PROTECTED]> Mime-Version: 1.0 On Jan 27, 1999, Ben Gertzfield <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil ------- End of forwarded message -------