Marcus Brinkmann <[EMAIL PROTECTED]> 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 ------------------------------ [EMAIL PROTECTED] "When all else fails, read the instructions." -- Cahn's Axiom "Our policy is, when in doubt, do the right thing." -- Roy L Ash