On Mon, Jan 07, 2002 at 01:57:37PM +0100, "Wikstr�m, M�rten" wrote: > Sorry for not paying enough attention to the FAQ. (although it is under the X >section). > But, the question remains. What good does the RUNPATH bring, that can't be done with >LD_LIBRARY_PATH?
The solution to shared libraries in non-standard places is RPATH. RPATH has the disadvantage that it can not be overridden by a user. So you can only use a different library by recompiling the program with a different rpath or replacing the file path. RUNPATH in the upcoming standard will be overridable and thus the right thing to do. It is compiled into the binary, so no environment setting is needed. This is important because LD_LIBRARY_PATH must be ignored for suid programs like xterm. So xterm only works correctly with RPATH or RUNPATH. ld.so.conf was never part of the ELF standard, as far as I know. It is a GNU/Linux specific extension. The other solution btw is to have all Debian GNU/Hurd libraries in /lib. This can be achieved either by giving all programs an empty prefix (or linking the prefix to /, like it is done with /usr), or to shadow all lib directories to the system lib directory. > > BTW, how does ld.so relate to the exec server? Who is > > responsible of what? As far as I can see, the exec server just loads and runs the binary. The code to fire up the linker and bring into the shared libraries is compiled into each executables: $ strings /bin/ls | grep ld.so /lib/ld.so Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd
