[ Thanks to Jeremy
Mack Wright for this link. ]
“Shared libraries are one of the many strong design
features of Linux, but can lead to headaches for inexperienced
users, and even experienced users in certain situations. Shared
libraries allow software developers keep the size of their
application storage and memory footprints down by using common code
from a single location. The glibc library is a good example of
this. There are two standardized locations for shared libraries on
a Linux system, and these are the /lib and /usr/lib directories. On
some distributions /usr/local/lib is included, but check the
documentation for your specific distribution to be sure. These are
not the only locations that you can use for libraries though, and
I’ll talk about how to use other library directories later.
According to the Filesystem Hierarchy Standard (FHS), /lib is for
shared libraries and kernel modules that are required for startup
and running in the root filesystem (/bin and /sbin), and /usr/lib
holds most of the internal libraries that are not meant to be
executed directly by users or shell scripts. The /usr/local/lib
directory is not defined in the latest version of the FHS, but if
it exists on a distribution it normally holds libraries that
aren’t a part of the standard distribution, including
libraries that the system administrator has compiled/installed
after the initial setup. There are some other directories like
/lib/security that holds PAM modules, but for our discussion
we’ll focus on /lib and /usr/lib.“The counterpart to the dynamically linked (shared) library is
the statically linked library. Whereas dynamically linked libraries
are loaded and used as they are needed by the applications,
statically linked libraries are either built into, or closely
associated with a program at the time it is compiled.”