I have been discovering all about library versioning. What I found came as a surprise to me and others especially those from a sysadmin background.
Basically it all comes down to the fact that the numbers on the end of a library name may not be what you expect and it is even more complex on OS X.
Libtool on Linux
For example consider the following libraries on a recent CentOS 6.2 install:
- /lib64/libparted-2.1.so.0.0.0
- /lib64/libproc-3.2.8.so
- /lib64/libgcrypt.so.11.5.3
These show the three different ways in which a library may be versioned. Chapter 7 of the libtool manual discuses this subject. Libtool library versions are purely concerned with the supported API or interface that the library supports. It determines what the linker will allow to be linked.
libtool library versions are described by three integers:
- current
- The most recent interface number that this library implements.
- revision
- The implementation number of the current interface.
- age
- The difference between the newest and oldest interfaces that this library imple- ments. In other words, the library implements all the interface numbers in the range from number current – age to current.
If two libraries have identical current and age numbers, then the dynamic linker chooses the library with the greater revision number.
This is (or should be) what you see for libgcrypt.so.11.5.3. Running gpg –version shows that the version of libgcrypt is in fact
# gpg --version gpg (GnuPG) 2.0.14 libgcrypt 1.4.5
The version of libgcrypt is 1.4.5 but its API is 11.5.3.
In order to set the Libtool library version you set the -version-info 11:5:3 flag using libmylib_la_LDFLAGS in your Makefile.am (See the automate manual).
By contrast /lib64/libproc-3.2.8.so has no numbers after the .so. They all appear before it. This reflects the fact that the developers, for whatever reason decided to use the version number of the application in the library. Running free gives
# free -V procps version 3.2.8
This is achieved by using the flag -release in place of -version-info in Makefile.am.
libparted-2.1.so.0.0.0 shows both. Running parted gives
# parted -v parted (GNU parted) 2.1
OS X
According to Fink the situation on OS X is slightly different. There is a “strict distinction between shared libraries and dynamically loadable modules”. On linux any ”shared code can be used as a library and for dynamic loading”. On OS X there are two types of library MH_DYLIB (a shared library) and MH_BUNDLE (a module). MH_DYLIB carry the extension .dylib and can be linked against in the familiar -lmylib at compile/link time. They can not be loaded as a module using dlopen(). MH_BUNDLE on the other hand can be dlopened. Apple suggest naming these .bundle however, much ported software uses .so instead. It is not directly possible to link against bundles as if they were shared libraries.