ELF objects make available global symbols to which other objects can bind. Some of these global symbols can be identified as providing the object's public interface. Other symbols are part of the object's internal implementation and are not intended for external use. An object's interface can evolve from one software release to another release. The ability to identify this evolution is desirable.
In addition, identifying the internal implementation changes of an object from one software release to another release might be desirable.
Both interface and implementation identifications can be recorded within an object by establishing internal version definitions. See Chapter 5, Application Binary Interfaces and Versioning for a more complete introduction to the concept of internal versioning.
Shared objects are prime candidates for internal versioning. This technique defines their evolution, provides for interface validation during runtime processing (see Binding to a Version Definition), and provides for the selective binding of applications (see Specifying a Version Binding). Shared objects are used as the examples throughout this appendix.
The following sections provide a simple overview, or cheat sheet, of the internal versioning mechanism provided by the link-editor and runtime linker as applied to shared objects. The examples recommend conventions and mechanisms for versioning shared objects, from their initial construction through several common update scenarios.