|
Building shared libraries is only marginally harder than building normal static libraries. There are a few constraints, all of which are easy to manage. There is also one major feature, designed to manage binary compatibility across library versions, that is unique to shared libraries.
Shared libraries are intended to preserve backward compatibility. That is, a binary built against an older version of the library still works when run against a newer version of the library. However, there needs to be a way to mark libraries as incompatible with each other for cases in which developers find it necessary to modify interfaces in a non-backward-compatible manner.
Managing Compatibility
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.
That is, you can use the rm command to remove it from the directory structure immediately; programs that are still using it keep it on the disk automatically until they exit.
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.
Incompatible Libraries
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.
Designing Compatible Libraries
When you are designing your own libraries, you need to know what makes a library incompatible. There are three main causes of incompatibilities:
-
Changing or removing exported function interfaces
-
Changing exported data items, except adding optional items to the ends of structures that are allocated within the library
-
Changing the behavior of functions to something outside the original specification
To keep new versions of your libraries compatible, you can:
-
Add new functions with different names rather than change the definitions or interfaces of existing functions.
-
When changing exported structure definitions, add items only to the end of the structures, and make the extra items optional or filled in by the library itself. Do not expand structures unless they are allocated within the library. Otherwise, applications will not allocate the right amount of data. Do not expand structures that are used in arrays
| 
Disclaimer
