* Enrico Weigelt <weig...@metux.de> [110104 16:07]: > And what exactly is the problem w/ redundant system pathes ?
They do not only include the library in question, but they include many other libraries. As paths supplied by the user are searched in before anything in the system path, this changes the order the system paths are searched in. This can both hide a user suplied search path (as it is searched now after /usr/lib, so replacing something there does no longer work). And it can change the order in the standard search path (so if your linker knows or is told that for the current format it needs to look first into some other directory to get the proper libc or things like that, the linker will see them too late). For example, on a amd64 lenny system run gcc -m32 -L/usr/lib hello.c and you get: /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc This is because it now first looks into those 64 bit libraries and luckily is able to determine they are not suitable and looks for better ones. And even this only works because /usr/lib/libc.so (a linker script, not an actual library) contains an "OUTPUT_FORMAT(elf64-x86-64)" so the linker knows it has the wrong file (most likely that is only there because it failed before without that). With that safeguard you get something like: /usr/bin/ld: skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6 /usr/bin/ld: cannot find /lib/libc.so.6 collect2: ld returned 1 exit status i.e. the link fails. And this is only the case with system libraries for the wrong format, i.e. something where the linker can easily detect something is wrong. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110104162622.ga2...@pcpool00.mathematik.uni-freiburg.de