Michael Moerz <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
