[blfs-dev] Shared library file locations

Bruce Dubbs bruce.dubbs at gmail.com
Sat Jul 7 16:15:39 PDT 2012


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




More information about the blfs-dev mailing list