The dlsym behavior in uClibc
Zheng Junling
zhengjunling at huawei.com
Mon Jan 5 12:45:53 UTC 2015
Hi, all:
I got a strange result when using dlsym to find a symbol in a shared library.
uClibc commit: f22cca4722fa66e424562e69f4afa2bca0af871d after v0.9.33
Assume that:
1) The symbol "print_sym" is defined in both liba.so and libb.so;
2) Libd.so depends on liba and libb in order: $(CC) -L./ -la -lb -Wl,-rpath=./ -shared -fPIC -o libd.so libd.c
and then, I passed the handle of libd.so to dlsym() to find the "print_sym" symbol:
pHandle = dlopen("./libd.so", RTLD_LAZY);
func = dlsym(pHandle, "print_sym");
thus, I got the "print_sym" symbol in libb.so. // Does it search symbol in this order: libd.so -> libb.so -> liba.so ?
However, when using glibc or eglibc, I would get this symbol in liba.so! // This looks like the normal behavior
More over, it looks like that uClibc-0.9.32 has the same behavior for dlsym with glibc and eglibc.
So, I doubt whether this is a bug or just a difference between different version,
and what the correct searching order is.
Does anybody have some ideas ?
Thanks!
More information about the uClibc
mailing list