I've been looking at libraries in /lib on my new system and have some issues I'd like to discuss. To start, I'll give a few definitions:
soname - libXX.so.x - a link to a real library name. This is used by ld.so to load the library when executing a program. realname - libXX.so.x.y[.z] - The actual library file. linkername - libXX.so - used by the ld command (usually via gcc) to create an executable or library. It is a usually a symlink to either the soname or the realname (it ends up being the same). libtool control file name - libXX.la Sometimes a package does not quite follow this naming convention. For example /lib/libpthread-2.15.so is a realname, but /lib/libpthread.so.0 is a soname link to the real name. On the other hand, /usr/lib/libpthread.so is a linker script. In LFS Section 6.10, we see that ld.so automatically searches for a soname in /usr/lib and /lib (and now in newer binutils, /usr/local/lib) In the past, I think that the ld's search for 'linkername', did not include /lib. When I run `gcc --print-search-dirs`, /lib is now there. Here is the issue. Some linkernames and libtool names are in /lib. What I have right now is: libpcre.la libpcre.so libpcrecpp.so libpcreposix.so liblzma.la liblzma.so libcap.so libkmod.so Moving the links is not much of a problem, but the .la and perhaps some .pc files may need to be changed. Does this need to be addressed, or should we leave it alone? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
