On Tue, Feb 22, 2005 at 12:48:27AM -0600, Bruce Dubbs wrote:
lrwxrwxrwx 1 root root 14 /lib/libpam.so.0-> libpam.so.0.78 -rwxr-xr-x 1 root root 30448 /lib/libpam.so.0.78
I think this is where the confusion is. .so symlinks != .so.version symlinks. .so.version is what ldd references whereas from what I understand a program that needs the lib at compile time looks for just the plain .so unless a version-dependent check is required by the program being built, in which case it will likely look for .so.version.
If the above understanding is correct, then .so.version should be in /lib if required at boot, and all .so links should be in /usr/lib because they are *only* used at compile time.
Great explanation..
With that said, though, it seems bad for organization to put a real lib in /lib only to obfuscate things by putting links to it in /usr/lib. I don't know why it is done that way except to keep /lib small, but if a lib is in /lib, so should *all* it's links be, IMO. Again, this is only for organization. I just don't see the benefit of splitting them up and causing us to have 2 dirs to work with for the same library.
The problem is that if you have lib-something.so in /lib and lib-something.a in /usr/lib, then when a package goes looking for lib-something to link into it's package it looks to /usr/lib sees the lib-something.a file and then stops looking any further and links against the static library instead of the dynamic one. I suppose we _could_ move all the lib-something.a and lib-something.la files to /lib as well, but then how big would /lib be by the time you finished with, oh lets say, Glibc! Besides I'm not even sure if the linker would do the right thing if everything is in /lib or if at least some of it has to be in /usr/lib. (besides it's not like we move the includes to /include and *.so symlinks kind of fall under that umbrella)
Jack Brown -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
