On Sat, Oct 07, 2006 at 05:21:47PM +0200, Bernhard R. Link wrote: > 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...
I agree that libraries picked up from the .la file would better be added at the end of the list of libraries. But I'm not sure if that's going to break something or not. I guess I need to think more about this. It libcwd only overrides functions from -ldl, it might make sense to put "-lcwd -ldl" in LDADD. Libtool would remove the first -ldl from the line, and it would also work. This is basicly the effect in upstream libtool, since there are 2 .la files with -ldl in it, and the version in Debian doesn't look at the second (libcwd.la). So only one -ldl is left, and it happens to be at the wrong place. But from looking at the description of libcwd, it's not designed to just replace -ldl. So this would add an uneeded DT_NEEDED entry for -ldl on the application in the default case. Also, I don't think that you want to say that if you link to -lcwd, you also always need to link to -ldl. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
