The shared library soname (cont.)
This diagram shows the steps that occur as the program is executed:
Compatible Versus Incompatible Libraries
We probably need to change a library over time.
A new library version is said to be compatible with an existing library version if all of the following conditions hold true:
The semantics of each function in the library remain unchanged.
All functions continue to produce same effect on global variables and returned arguments.
All functions continue to return the same result values.
Performance improvements and bug fixes (perhaps resulting in closer conformance to specified behavior) are compatible changes.
No function in the library API is removed.
New functions can be added.
The structures exported (i.e. allocated within and returned) by each function remain unchanged.
Possible exception: new items may be added to the end of the existing structure
If any of these conditions is violated, then the new library version is incompatible with the previous version.
Shared library versions and naming
If a new version of a shared library is compatible with an existing library, we can make a new minor version of the library.
If a new version of a shared library is incompatible with an existing library, we must make a new major version of the library.
Constraint: it must be possible to continue running programs requiring the older version of the library.
Solution: a naming convention is used for shared library real names and sonames.
Shared library versions and naming (cont.)
Real name
Name of the file containing library code.
Format: libname.so.major-id.minor-id
Major version identifieris a number which is sequentially incremented with each incompatible release of the library.
Minor version identifier distinguishes different compatible minor versions of a library within the same major version.
Usually either a number, or two numbers sep