Martin Buchholz <martin(a)xemacs.org> writes:
Well, the way it *should* work is that the RPATH baked into the
executable is searched first, and then, if not all libraries are
found, /etc/ld.so.conf is searched, and if not all libraries are
found, the hardcoded /usr/lib is searched.
However as I said before that way you can no longer override the search using
LD_LIBRARY_PATH
prompt> gcc main.c -o main
prompt> ldd main
libc.so.6 => /lib/libc.so.6 (0x4001a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
prompt> gcc main.c -Wl,-rpath=/tmp/vroonhof/librpath -o mainrpath
prompt> ldd mainrpath
libc.so.6 => /tmp/vroonhof/librpath/libc.so.6 (0x40014000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
prompt> setenv LD_LIBRARY_PATH /tmp/vroonhof/libs
prompt> ldd main
libc.so.6 => /tmp/vroonhof/libs/libc.so.6 (0x40014000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
prompt> ldd mainrpath
libc.so.6 => /tmp/vroonhof/librpath/libc.so.6 (0x40014000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Everything also on Redhat 6.0. However that might simply be the price
to pay to get rid of the libXaw problem (short of more drastic
measures like not subclassing any widgets or linking plain athena statically).
Jan