The Linux Programming Interface

(nextflipdebug5) #1

850 Chapter 41


41.8 Compatible Versus Incompatible Libraries


Over time, we may need to make changes to the code of a shared library. Such
changes result in a new version of the library that is either compatible with previous
version(s), meaning that we need to change only the minor version identifier of the
library’s real name, or incompatible, meaning that we must define a new major version
of the library.
A change to a library is compatible with an existing library version if all of the
following conditions hold true:

z The semantics of each public function and variable in the library remain
unchanged. In other words, each function keeps the same argument list, and
continues to produce its specified effect on global variables and returned argu-
ments, and returns the same result value. Thus, changes that result in an
improvement in performance or fix a bug (resulting in closer conformance to
specified behavior) can be regarded as compatible changes.
z No function or variable in the library’s public API is removed. It is, however,
compatible to add new functions and variables to the public API.
z Structures allocated within and returned by each function remain unchanged.
Similarly, public structures exported by the library remain unchanged. One
exception to this rule is that, under certain circumstances, new items may be
added to the end of an existing structure, though even this may be subject to
pitfalls if, for example, the calling program tries to allocate arrays of this struc-
ture type. Library designers sometimes circumvent this limitation by defining
exported structures to be larger than is required in the initial release of the
library, with some extra padding fields being “reserved for future use.”

If none of these conditions is violated, then the new library name can be updated
by adjusting the minor version of the existing name. Otherwise, a new major version
of the library should be created.

41.9 Upgrading Shared Libraries


One of the advantages of shared libraries is that a new major or minor version of a
library can be installed even while running programs are using an existing version.
All that we need to do is create the new library version, install it in the appropriate
directory, and update the soname and linker name symbolic links as required (or,
more usually, have ldconfig do the job for us). To produce a new minor version (i.e.,
a compatible upgrade) of the shared library /usr/lib/libdemo.1.0.1, we would do the
following:

$ su
Password:
# gcc -g -c -fPIC -Wall mod1.c mod2.c mod3.c
# gcc -g -shared -Wl,-soname,libdemo.so.1 -o libdemo.so.1.0.2 \
mod1.o mod2.o mod3.o
# mv libdemo.so.1.0.2 /usr/lib
# ldconfig -v | grep libdemo
libdemo.so.1 -> libdemo.so.1.0.2 (changed)
Free download pdf