Every Linux shared library is assigned a special name, called a soname, that includes the name of the library and a version number. When developers change interfaces, they increment the version number, altering the name. Some libraries do not have stable interfaces; developers may change their interface in an incompatible way when a new version is released that has changed only a minor number. Most library developers attempt to maintain stable interfaces that change in an incompatible manner only when they release a new major version of the library.

For example, the developers and maintainers of the Linux C library attempt to maintain backward compatibility for all releases of the C library with the same major number. Version 5 of the C library has gone through five minor revisions, and with few exceptions, programs that worked with the first minor revision work with the fifth. (The exceptions have been poorly coded programs that took advantage of C library behavior that was not specified or that was buggy in older versions and fixed in newer versions.)

Because all version 5 C libraries are intended to be backward compatible with older versions, they all use the same soname—libc.so.5—which is related to the name of the file in which it is stored, /lib/libc.so.5. m. r, where m is the minor version number and r is the release number.

Applications that link against a shared library do not link directly against /lib/libc.so.6 (for instance), even though that file exists. The ldconfig program, a standard Linux system utility, creates a symbolic link from /lib/libc.so.6 (the soname) to /lib/libc-2.3.2.so, the real name of the library. This makes upgrading shared libraries easy. To upgrade from 2.3.2 to 2.3.3, it is necessary only to put the new libc-2.3.3.so into the /lib directory and run ldconfig. The ldconfig looks at all the libraries that provide the libc.so.6 soname and makes the symbolic link from the soname to the latest library that provides the soname. Then all the applications linked against /lib/libc.so.6 automatically use the new library the next time they are run, and /lib/libc-2.3.2.so can be removed immediately, since it is no longer in use.^[2]

Unless you have a particular reason to do so, do not link against a specific version of a library. Always use the standard -l libname option to the C compiler or the linker, and you will never accidentally link against the wrong version. The linker will look for the file liblibname.so, which will be a symlink to the correct version of the library.

So, for linking against the C library, the linker finds /usr/lib/libc.so, which tells the linker to use /lib/libc.so.6, which is a link to the /lib/libc-2.3.2.so file. The application is linked against libc-2.3.2.so’s soname, libc.so.6, so when the application is run, it finds /lib/libc.so.6 and links to libc-2.3.2.so, because libc.so.6 is a symlink to libc-2.3.2.so.

When a new version of a library needs to be incompatible with an old version, it should be given a different soname. For instance, to release a new version of the C library that is incompatible with the old one, developers used the soname libc.so.6 instead of libc.so.5, which shows that it is incompatible and also allows applications linked against either version to coexist on the same system. Applications linked against some version of libc.so.5 will continue to use the latest library version that provides the libc.so.5 soname, and applications linked against some version of libc.so.6 will use the latest library version that provides the libc.so.6 soname.

When you are designing your own libraries, you need to know what makes a library incompatible. There are three main causes of incompatibilities:

To keep new versions of your libraries compatible, you can:

As an extremely simple but still instructive example, we have created a library that contains one short function. Here, in its entirety, is libhello.c:

1: /* libhello.c */
2:
3: #include <stdio.h>
4:
5: void print_hello(void) {
6:     printf("Hello, library.
");
7: }

Of course, we need a program that makes use of libhello:

1: /* usehello.c */
2:
3: #include "libhello.h"
4:
5: int main (void) {
6:     print_hello();
7:     return 0;
8: }

The contents of libhello.h are left as an exercise for the reader.

In order to compile and use this library without installing it in the system, we take the following steps:

When you run a program, the dynamic loader usually looks in a cache (/etc/ld.so.cache, created by ldconfig) of libraries that are in directories mentioned in /etc/ld.so.conf to find libraries that the program needs. However, if the LD_LIBRARY_PATH environment variable is set, it first dynamically scans the directories mentioned in LD_LIBRARY_PATH (which has the same format as the PATH environment variable) and loads all the directories it finds in the path, before it looks in its cache.

This means that if you want to use an altered version of the C library when running one specific program, you can put that library in a directory somewhere and run the program with the appropriate LD_LIBRARY_PATH to access that library. As an example, a few versions of the Netscape browser that were linked against the 5.2.18 version of the C library would die with a segmentation fault when run with the standard 5.3.12 C library because of a more stringent enforcement of malloc() policies. Many people put a copy of the 5.2.18 C library in a separate directory, such as /usr/local/netscape/lib/, move the Netscape binary there, and replace /usr/local/bin/netscape with a shell script that looks something like this:

#!/bin/sh
export LD_LIBRARY_PATH=/usr/local/netscape/lib:$LD_LIBRARY_PATH
exec /usr/local/netscape/lib/netscape $*

Sometimes, rather than replacing an entire shared library, you wish to replace only a few functions. Because the dynamic loader searches for functions starting with the first loaded library and proceeds through the stack of libraries in order, it would be convenient to be able to tack an alternative library on top of the stack to replace only the functions you need.

An example is zlibc. This library replaces file functions in the C library with functions that deal with compressed files. When a file is opened, zlibc looks for both the requested file and a gzipped version of the file. If the requested file exists, zlibc mimics the C library functions exactly, but if it does not exist, and a gzipped version exists instead, it transparently uncompresses the gzipped file without the application knowing. There are limitations, which are described in the library’s documentation, but it can trade off speed for a considerable amount of space.

There are two ways to preload a library. To affect only certain programs, you can set an environment variable for the cases you wish to affect:

LD_PRELOAD=/lib/libsomething.o exec /bin/someprogram $*

However, as with zlibc, you might want to preload a library for every program on the system. The easiest way to do that is to add a line to the /etc/ld.so.preload file specifying which library to preload. In the case of zlibc, it would look something like this:

/lib/uncompress.o