I think the whole problem is a bit dificil, as this symbol overwriting
does depend too much on the order of linking, and of different levels of
loading.
Consider the following case, where liby.o redefines dlopen returning -1
and test.c has a main prints what dlopen outputs:
gcc -Wall -g -O0 -o libx.o -c libx.c
gcc --shared -o libx.so libx.o -ldl
gcc -Wall -g -O0 -o liby.o -c liby.c
gcc --shared -o liby.so liby.o -ldl
gcc -Wall -g -O0 -o test.o -c test.c
gcc test.o -L. -lx -ly -ldl -o test
gcc test.o -L. -lx -ly -o test2
gcc test.o -L. -lx -ldl -ly -o test3
gcc -Wall -g -O0 -o liba.o -c liba.c
gcc --shared -Wl,-rpath,. -o liba.so liba.o -L. -ly -ldl
gcc test.o -L. -lx -la -L. -o test4
test and test2 return -1, because libdl is loaded after liby
(because the dynamic linker seems to first load all NEEDED libs and
only then the dependencies)
while test3 and test4 return the original dlopen's value.
In test3 case, because dl is processed before liby because at the same
level, in test4 case because first the dependencies for liba (which is
libdl) seem to get loaded and only then the dependencies for liba
(which is liby and libdl).
As this symbol overwriting by cwd is so tricky with the link order, I
guess the best ways to work around would be to either always
specify "-lcwd -ldl", if that causes libtool to not place a -ldl before,
or on libtools side to always put all dependency libraries got from
.la dependency lines at the end after all other libraries to mimic the
behaviour the dynamic linker would have if there were only dynamic libraries
and no depdency lines, so das libraries using such deep asumptions about
the linking order can continue their black magic...
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
