Re: -rpath with libtool and Debian Linux
On Jan 29, 1999, Jason Gunthorpe <jgg@ualberta.ca> wrote:
>> > Didn't we decide that all of the available alternatives that you have
>> > suggested are not a feasable solution (does this mail help make it clear
>> > why)?
> On 29 Jan 1999, Alexandre Oliva wrote:
>> You may have missed the ugly one I was referring to, that I suggested
>> in the very beginning of this discussion, that would work even for
>> packages that were distributed with older versions of libtool:
>> configure the packages to use a gcc or ld wrapper that removes
>> switches such as -rpath /usr/lib from the command line then call the
>> appropriate program.
> So you agree that we should be able to choose to disable rpath but you
> feel that we should do extra work to advoid it for libtool because it does
> not fit your beliefs of how shared libraries work? What about other dists
> that do the same thing? We are not the only linux dist to use this scheme!
I agree that libtool may, some day, allow users to do that in a
portable fashion. But I still don't see how modifying the current
version of libtool would help you fix the problem of backward
compatibility for already compiled programs or for packages
distributed with older versions of libtool. Therefore, the fix you
really need is not in libtool, is in the dynamic loader.
>> This will have the extra benefit of fixing other packages that don't
>> use libtool, but happen to specify -rpath on their own.
> Actually virtually every other package we would just hand edit the
> makefiles, libtool kinda makes that impossible.
Yep. Now you have to edit a single libtool script, instead of all the
Makefiles of the package. Ain't tha progress?
>> > - rpath is bad because it disables LD_LIBRARYPATH
> It prevents you from using LD_LIBRARY_PATH to superceed the default
> location of libraries, which is partially what it does
Not according to the Posix specification.
> rpath prevents library searching and thus kills this functionality.
It doesn't prevent library searching, it just takes precedence over
it. If the library is not found in the rpath specified at link-time,
the library is searched in other directories, such as the ones
specified in LD_LIBRARY_PATH.
>> > - rpath is bad because it disables the linkers automatic versioning >
>> mechanism
>> Does it? You mean, that hack in ld.so that adds /usr/lib/libc5 to the
>> library search path in certain circumstances? The hack is incomplete,
>> you just have to fix it.
> See the other messages - it is not a hack and it is not horribly
> incomplete.
It doesn't work for applications that have chosen to hard-code
/usr/lib or /usr/lib/X11R6 in their code, for whatever reason,
therefore I can only see two possible conclusions:
1) your choice to move libraries around was a bad idea, because it
causes certain applications to break
2) the code in the dynamic loader that chooses the `right' version of
a library is incomplete, in the sense that it doesn't choose the
`right' version when shared library paths are hard-coded in the
application
--
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: