hmm...
[EMAIL PROTECTED] /1]$ ldd /bin/sleep linux-gate.so.1 => (0xffffe000) libm.so.6 => /lib/libm.so.6 (0xb7fc5000) librt.so.1 => /lib/librt.so.1 (0xb7fbd000) libc.so.6 => /lib/libc.so.6 (0xb7eaf000) /lib/ld-linux.so.2 (0xb7fec000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7e9d000)
[EMAIL PROTECTED] /]$ ls -l /lib/libm* -rwxr-xr-x 1 root root 146040 Feb 11 20:48 /lib/libm-2.3.4.so lrwxrwxrwx 1 root root 13 Feb 11 22:14 /lib/libm.so.6 -> libm-2.3.4.so -rwxr-xr-x 1 root root 13724 Feb 11 20:48 /lib/libmemusage.so
[EMAIL PROTECTED] /]$ file /lib/libm-2.3.4.so
/lib/libm-2.3.4.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped
How does that gel with the paragraphs above? libm-2.3.4.so is the actual runtime library, not only the compile\linking library...
-- - Steve Crosby
The problem is here is just that Glibc is a bit weird with how they name their libraries for whatever reason. If you notice there is an "unversioned *.so symlink" in /usr/lib. On my system I get:
/usr/lib/libm.so -> ../../lib/libm.so.6
So, things still work the same, just the naming is a bit off.
Here's how I look at it:
You go to compile something, it decides that it want's libm and starts off looking at /usr/lib to see what it can find. It comes across a file /usr/lib/libm.so which is linked to a file called /lib/libm.so.6. based on this it tells the linker to link the resulting binary to a file named /lib/libm.so.6.
When you run the program it sees that it need to load up the file /lib/libm.so.6 and in doing so ends up following the symlink and ends up actually loading /lib/libm.2.3.4.so in the process.
Some months later you decide to upgrade Glibc to version 2.3.5 (I'll make the assumption the 2.x.x versions are ABI compatible). so now you have:
/usr/lib/libm.so -> ../../lib/libm.so.6
/lib/libm.so.6 -> libm.2.3.5.so
/usr/libm.2.3.4.so (the old left over lib)
/usr/libm.2.3.5.so (the newley installed lib)
Now when we run the binary it will try to load /lib/libm.so.6 again, but this time, it ends up using libm.2.3.5.so instead, and libm.2.3.4.so just gets left by the way side..
Then, a while later you decide to install the brand new Glibc 3.0! (Glibc is probably a bad example cause Glibc 3.0 seems to me like something out of science fiction..) ..Now, you end up with this:
/usr/lib/libm.so -> ../../lib/libm.so.7 /lib/libm.so.6 -> libm.2.3.5.so /lib/libm.so.7 -> libm.3.0.so (oooh this is new!) /usr/libm.2.3.4.so (now old and crusty) /usr/libm.2.3.5.so (also crusty) /lib/libm.3.0.so (brand spanking new lib with incompatible ABI)
So now if you run the binary you made at the start it will use (tada) _the same old lib as before!_ ie. it will look to libm.so.6 (because that was hardcoded at compile time) and see it _still_ points to libm.2.3.5.so.
_However_ if you were to compile it over again the linker would start off (again) by looking for libm.so, starting in /usr/lib, it would see that it now points to /lib/libm.so.7 and hardcode that into the new binary instead. Then when the new binary is run it will follow libm.so.7 and see that it now needs to use /lib/libm.3.0.so instead.
I hope that helps a bit.
Jack Brown -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
