Re: -rpath with libtool and Debian Linux
Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> On Fri, Jan 29, 1999 at 03:41:46PM -0600, Gordon Matzigkeit wrote:
> > >> I don't understand this comment. Which "trouble" with "--rpath" do
> > >> you mean?
> >
> > AO> The exact problem the Debian developers have been complaining
> > AO> about. The more I think about the problem, the more I see that
> > AO> the problem they're facing is an incomplete hack of ld.so, in
> > AO> that it modifies the library search path under certain
> > AO> circumstances, but not in all circumstances that would need it.
> >
> > Exactly.
>
> Mmh. I think I see the point now, and I have to agree.
> So, the problem we are facing is twofold:
>
> * How can Debian hack around the rpath problem, so user can use third party
> software which is libc5+rpath.
>
> * Is there a better way to do a library transition? I think it is very
> obvious, that the only correct behaviour is to change the
> library/soname of all involeved libraries when doing a transition.
> So we had to move either from libfoo.2 to libfoog.2, libfoo.libc6.2,
> libc6/libfoo.2 or whatever, until a new library with a new, incompatible,
> soname is released. Changing the name does not look correct, so we had
> to change soname or path.
Caveat: I'm a novice at these issues.
IMHO (with 20/20 hindsight), it would have been much nicer if the
libc5->libc6 transition had used a different mechanism -- something
akin to $_RLD_ROOT of IRIX.
The idea of _RLD_ROOT is that if that env. variable is set, it is
prepended to every runpath in the binary + every default path.
E.g. if _RLD_ROOT="/mnt1:/mnt2:", and you have a binary with -rpath
set to "/usr/foo/lib" and, the default library search path is
"/lib:/usr/lib". The set of paths searched by the linker are, in
order:
/mnt1/usr/foo/lib
/mnt2/usr/foo/lib
/usr/foo/lib
$LD_LIBRARY_PATH
/mnt1/lib
/mnt2/lib
/lib
/mnt1/usr/lib
/mnt2/usr/lib
/usr/lib
(I may have got the specifics wrong, but this should be the general
idea.)
The "better" way for libc5/6 hack would have been to modify
ld-linux.so.1 (the libc5 ELF loader) to act _as if_ the _RLD_ROOT
env. var. was set to `/usr/compat-glibc1:'. This way, the libc5
libraries could have been moved into to the /usr/compat-glibc1 tree
maintaining the same tree structure, and would automatically have
worked with any `-rpath's.
E.g., xlib6 (the libc5 compatible X library) could have put its
libraries in
/usr/compat-glibc1/usr/X11R6/lib
(if it originally put it in `/usr/X11R6/lib') and libc5 could have put
its library either in /lib or in /usr/compat-glibc1/lib.
Moving from `bo' to `hamm' for libc5 libraries could just have been a
matter of dpkg-repack or some similar tool.
Of course, I'm not conversant with all the issues, and could be
completely wrong.
- Hari
--
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions." -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing." -- Roy L Ash
Reply to: