Re: RPATH question
Michael Moerz <aon.912411198@aon.at> writes:
MM> First question: -rpath specifies where a library (eventually)
MM> will be installed, but what is so bad about that?
Let's say, hypothetically, that you were used to building all of your
X programs with '-Wl,-rpath,/usr/X11R6/lib'. It works, no harm in
that, right? But then Debian decides to, say, change versions of libc
to something that's radically different. The old X libraries move to
/usr/old-libc/lib, and /usr/X11R6/lib contains the new X libraries.
In the absence of the -rpath flag, things work fine: ld.so looks at
the binary and notices that you need the old libc and the old X
libraries, and gets everything correct. But with -rpath, ld.so
preferentially loads the libraries in /usr/X11R6/lib, which are linked
against the new libc. The result is that you get both old and new
libraries trying to run at the same time, a recipe for instant
segmentation faults.
Yes, this has happened to Debian before, with the libc5 to glibc
upgrade. (And yes, it happened right when I switched from Slackware
to Debian unstable, and I had to use emacs on my fvwm2 binary so I
could log in.) But that's essentially why Debian policy frowns upon
the use of -rpath.
MM> second: Is thst so bad that I should change sdlmm-config to not
MM> supply rpath?
Yes.
--
David Maze dmaze@debian.org http://people.debian.org/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell
Reply to: