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

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


(I may have got the specifics wrong, but this should be the general

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


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