Re: devel files and libraries in /lib
* Enrico Weigelt <weigelt@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
Reply to: