dynamic library versioning

can someone point me to some documentation on how shared object(dynamic library) versioning works, specifically what the numbers after the .so mean, the purpose of ldconfig and libtool. ive looked for documentaion on this but found very little, the bit i found was in the rute users guide but i didnt follow it very well.

is this one of the mythical topics that is passed down from guru to guru without reaching the general population? id love to go and RTFM if only i knew where the FM was.

this is the only documentation i found, sec 23.2, but i didnt follow the paragraph that starts "At the moment, we are interested in libsimple_math.so.1.0", just an explanation of that paragraph would be great.

This is just a loose interpretation. I am not a developer or a technical writer, just a hack who likes trying to figure stuff out.

At the moment, we are interested in libsimple_math.so.1.0. Note how it matches the SOVERSION variable in the Makefile. Note also how we have chosen our symlinks. We are effectively allowing mytest to link with any future libsimple_math.so.1.0.? (were our simple_math library to be upgraded to a new version) purely because of the way we have chosen our symlinks. However, it will not link with any library libsimple_math.so.1.1.?, for example. As developers of libsimple_math, we are deciding that libraries of a different minor [For this example we are considering libraries to be named libname .so.major .minor .patch]version number will be incompatible, whereas libraries of a different patch level will not be incompatible. We could also change SOVERSION to libsimple_math.so.1. This would effectively be saying that future libraries of different minor version numbers are compatible; only a change in the major version number would dictate incompatibility.

Ok, now keep in mind his makefile in section 23.1. There he declares "SOVERSION = libsimple_math.so.1.0" and creates the 2 symlinks you see just above section 23.2.:

lrwxrwxrwx 1 root root 23 Sep 17 22:02 libsimple_math.so -> libsimple_math.so.1.0.0 lrwxrwxrwx 1 root root 23 Sep 17 22:02 libsimple_math.so.1.0 -> libsimple_math.so.1.0.0

The first symlink, ended in .so is the "SONAME" symlink and really doesn't care which version the SO is. The second is the one he explains that must be linked to a compatable SO. When the makefile is processed, it will look for (because he set the SOVERSION) libsimple_math.so.1.0.? where ? is equal to any one character. In his versioning convention (which seems very common) the ? will apply to any patched libsimple_math.so with a major version of 1 and a minor version of 0. He goes on to explain how we would set up the makefile's SOVERSION declaration so that our code is compatable with any minor version of the major version 1.

Hope that helps at all, and if I could provide more info, I would.



##NOTE: The above quotes are Copyright © 2002 Paul Sheer used by permission from the author given by his Terms and Conditions.

Hi kev82,

I am new in unix programing. So I don't know about shared object.
If you help me on my question then very great. I don't know how to use awk.

Thanks

Here is the relevant section of the libtool documentation. Note that there is no established standard and software developers may break the rules. However, libtool is extremely widely used and you can assume that many libraries do comply with its views.

I hope that helps.

Libtool's versioning system
===========================

Libtool has its own formal versioning system. It is not as flexible
as some, but it is definitely the simplest of the more powerful
versioning systems.

Think of a library as exporting several sets of interfaces,
arbitrarily represented by integers. When a program is linked against
a library, it may use any subset of those interfaces.

Libtool's description of the interfaces that a program uses is
simple: it encodes the least and the greatest interface numbers in the
resulting binary (FIRST-INTERFACE, LAST-INTERFACE).

The dynamic linker is guaranteed that if a library supports _every_
interface number between FIRST-INTERFACE and LAST-INTERFACE, then the
program can be relinked against that library.

Note that this can cause problems because libtool's compatibility
requirements are actually stricter than is necessary.

Say `libhello' supports interfaces 5, 16, 17, 18, and 19, and that
libtool is used to link `test' against `libhello'.

Libtool encodes the numbers 5 and 19 in `test', and the dynamic
linker will only link `test' against libraries that support _every_
interface between 5 and 19. So, the dynamic linker refuses to link
`test' against `libhello'!

In order to eliminate this problem, libtool only allows libraries to
declare consecutive interface numbers. So, `libhello' can declare at
most that it supports interfaces 16 through 19. Then, the dynamic
linker will link `test' against `libhello'.

So, 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 implements. 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.

The purpose of libtool is to hide system specific details of shared libraries to the developer. If a developer wants to create a shared library without libtool, it needs to follow rules that differ between two compilers (say under GNU/Linux and FreeBSD). By using libtool the programmer only needs to learn the libtool way and relies on libtool to know the compilers / operating systems variants.

Libtool is criticized by some people because it does not know all compilers and all operating systems. Yet, it knows a lot of them. For a widely used program, it therefore makes sense to use libtool and add hand written cases whenever libtool fails to perform. A dedicated developer would figure out how to enrich libtool so that it covers the missing compiler / operating system, but that requires some time for someone unfamiliar with libtool.

From the point of view of a developer using libtool generated shared libraries (versus a developer building such a library), libtool provides a set of functions to dynamically load these libraries. This need typically arises when a program wants to load plugins. This set of functions (libltdl) replaces the dlopen, dlsym and dlclose functions usually provided with the C library. Subtle operating system differences makes it difficult to load shared libraries in a portable way, hence the need for libltdl. In theory, it would be better if all operating systems behaved in the same way. It seems that dlopen being part of the single unix specification (http://www.opengroup.org/onlinepubs/...sh/dlopen.html) was not enough, probably because dynamic library handling is highly dependent on deeper operating system choices.

Originally posted by kev82 is this one of the mythical topics that is passed down from guru to guru without reaching the general population? id love to go and RTFM if only i knew where the FM was. this is the only documentation i found, sec 23.2, but i didnt follow the paragraph that starts "At the moment, we are interested in libsimple_math.so.1.0", just an explanation of that paragraph would be great.

At the moment, we are interested in libsimple_math.so.1.0. Note how it matches the SOVERSION variable in the Makefile. Note also how we have chosen our symlinks. We are effectively allowing mytest to link with any future libsimple_math.so.1.0.? (were our simple_math library to be upgraded to a new version) purely because of the way we have chosen our symlinks. However, it will not link with any library libsimple_math.so.1.1.?, for example. As developers of libsimple_math, we are deciding that libraries of a different minor [For this example we are considering libraries to be named libname .so.major .minor .patch]version number will be incompatible, whereas libraries of a different patch level will not be incompatible. We could also change SOVERSION to libsimple_math.so.1. This would effectively be saying that future libraries of different minor version numbers are compatible; only a change in the major version number would dictate incompatibility.

As said, DLL versioning is to be able to have two or more version's of the same DLL in the same directory, and be able to link them without compatibility problem's apon change to said DLL.

This allow's any future version of "libsimple_math.so.1.0?" to be link's with "file" , and not screw up compatibility, but it would not work for and change to major (an example of this is versioning system is bolded out above)
Feel free to ask more question's if you don't understand.
And in closing it doesn't make sence...because they speak of (bolded out above) a change to minor.

moderators please delete, druken people cant be trusted with passwords

UNIX Programmer's guide(thats the exact title, it's not programmer's reference manual or anything else) is supposed to contain a good read on shared library for ex: mkshlib(1). u might have already read it. sorry if didn't help.