The /lib directory contains the shared images of the shared libraries, that is the actual machine code that is run when a routine in a shared library is called. They are not in /usr/lib because /usr can be on a different partition and might not be mounted when the shared images are needed (e.g. by programs in /bin ).
A shared library usually has a name such as /lib/libc.so.4.3.2 , which in this case would indicate version 4.3.2 of the standard C library. The .so bit indicates that it is a shared library image (``shared object'', if you prefer).
There can be several versions of a shared library installed at the same time. A typical reason for this is that when a shared library is upgraded, the old version is usually kept around until the new version has proved to be reliable. Also, some programs are linked so that they require a specific version of a shared library. Most programs, however, are linked to use a name like /lib/libc.so.4 , i.e. using only the major version number. That name is then actually a symlink to whatever version of the shared library that is installed and intended to be used on the system. The contents of /lib might then look like
Note that there seems to be two versions of the C math
library, libm.so.4.0
and libm.so.4.3.2
. The symlink
libm.so.4
points at the latter, so that's what gets used
unless a program explicitly requires the other one. The
reason why both versions are on the disk might be that some
program that is used on the system does indeed require that
version.
A shared library image can be updated by shutting down the system, booting with a special boot floppy, or by some other means that doesn't mount the normal root filesystem, and then copying the new shared library image to the /lib
directory and fixing up the symlink. The system can then be brought up in a normal manner. This procedure avoids the problems described below if something goes wrong during the update, since the shared library images on the partition that is being updated aren't ever used.
This is a bit of work, however, so the way it is actually done in practice is to do it while the system is up and running. There is no problem with this, except for a distinct possibility of making it impossible to run any program that uses a shared library, if you make a mistake. The correct way to do it is
with appropriate values substituted for new and major. Note that it is imperative that the operation of replacing the old link with the new one is done atomically, in one operation, not as two separate commands. The following is an incorrect way of updating the link:
The problem with the above two commands is that what happens after the rm ? When ln starts it tries to use the shared library /lib/libc.so.4 , but that was just deleted! Not only can't you create the new link, you can't run any other program that uses the shared library either! If you reboot and use a different root partition (and therefore a different set of shared libraries) to do the update, or if you use some carefully selected statically linked binaries ( ln comes to mind), you can reduce the probability of this problem, if you are afraid you are going to make the mistake.