Re: -rpath with libtool and Debian Linux
On 29 Jan 1999, Alexandre Oliva 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)?
>
> 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!
> 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.
> > - rpath is good because it allows a biary to have a shared library
> > in a non-standard place without requiring the user to use
> > LD_LIBRARYPATH or the sysadmin to add that place to the search
> > path
> > - rpath is bad because it disables LD_LIBRARYPATH
>
> It does not disable it, it just precedes LD_LIBRARY_PATH. AFAIK, the
> purpose of LD_LIBRARY_PATH is to help a program find a library that
> was moved, and it does fulfil this purpose as long as you don't
> install another (in)compatible library in place of the moved library.
It prevents you from using LD_LIBRARY_PATH to superceed the default
location of libraries, which is partially what it does - rpath prevents
library searching and thus kills this functionality.
> > - 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.
Jason
Reply to: