I think there's a bug in the dlopen(3) page. It says that
"If the executable file for the calling program contains a DT_RUN‐
PATH tag, then the directories listed in that tag are searched."
But that's not the case, as demonstrated by this example:
---
echo -e '#include <dlfcn.h>\n#include <stdio.h>\nvoid lib1(void) { if
(dlopen("liblib2.so", RTLD_NOW)) printf("ok\\n"); }' > lib1.c
gcc lib1.c -shared -fPIC -o liblib1.so -ldl
cp liblib1.so liblib2.so
echo "void lib1(void); int main(void) { lib1(); }" > main.c
gcc main.c -o main $PWD/liblib1.so -Wl,-rpath,$PWD -Wl,--enable-new-dtags
./main # does not print 'ok'
---
If, on the other hand, you add the DT_RUNPATH tag to the library that calls
dlopen, it gets used and liblib2.so is found.
This patch (http://sources.redhat.com/ml/libc-hacker/2002-10/msg00048.html)
and the answer (http://sourceware.org/ml/libc-hacker/2002-11/msg00011.html)
indicate that this behavior is expected by the glibc developers and not a bug.
The full search seems to scan these directories, from top to bottom:
Unless loading object has RUNPATH:
RPATH of the loading object,
then the RPATH of its loader (unless it has a RUNPATH), ...,
until the end of the chain, which is either the executable
or an object loaded by dlopen
Unless executable has RUNPATH:
RPATH of the executable
LD_LIBRARY_PATH
RUNPATH of the loading object
ld.so.cache
default dirs
Regards,
Christian Kamm
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
