Can someone explain about Linux library naming?

Question

When I create a library on Linux, I use this method:

1. Build: libhelloworld.so.1.0.0
2. Link: libhelloworld.so.1.0.0 libhelloworld.so
3. Link: libhelloworld.so.1.0.0 libhelloworld.so.1

The versioning is so that if you change the public facing methods, you can build to libhelloworld.so.2.0.0 for example (and leave 1.0.0 where it is), so that applications using the old library won't break.

However, what's the point in naming it 1.0.0 - why not just stick with libhelloworld.so and libhelloworld.so.1?

Also, is it best practice to name your library using 1.0.0 for example, or just 1?

g++ ... -Wl,-soname,libhelloworld.1

Or:

g++ ... -Wl,-soname,libhelloworld.1.0.0

Answer 1

The primary advantage of this method is easily letting users know which version of the library they have. For example, if I know a bug I'm getting was fixed in 1.0.4 I can easily check what version of the library I am linking against, and know if that's the right way to fix the bug.

This number is referred to as the "shared object version" or "soversion" and is part of the ELF binary standard. IBM has a good overview of ELF at http://www.ibm.com/developerworks/power/library/pa-spec12/.

Answer 2

The way you're supposed to form the x.y.z version is like this:

1. The first number (x) is the interface version of the library. Whenever you change the public interface, this number goes up.
2. The second number (y) is the revision number of the current interface. Whenever you make an internal change without changing the public interface, this number goes up.
3. The third number (z) is not a build number, it is the backwards-compatability count. This tells you how many previous interfaces are supported. So for example if interface version 4 is strictly a superset of interfaces 3 and 2, but totally incompatible with 1, then z=2 (4-2 = 2, the lowest interface number supported)

So the x and z numbers are very important for the system to determine if a given app can use a given library, given what the app was compiled against. The y number is mainly for tracking bug fixes.

Answer 3

From an old email I sent to a colleague about this question:

Let's look at libxml as an example. First of all, shared objects are stored in /usr/lib with a series of symlinks to represent the version of the library availiable:

lrwxrwxrwx 1 root root     16 Apr  4  2002 libxml.so -> libxml.so.1.8.14
lrwxrwxrwx 1 root root     16 Apr  4  2002 libxml.so.1 -> libxml.so.1.8.14
-rwxr-xr-x 1 root root 498438 Aug 13  2001 libxml.so.1.8.14

If I'm the author of libxml and I come out with a new version, libxml 2.0.0 that breaks interface compatiblity with the previous version, I can install it as libxml.so.2, and libxml.so.2.0.0. Note that it is up to the application programmer to be responsible about what he links to. If I'm really anal, I can link directly to libxml.so.1.8.14 and any other version will result in my program not running. Or I can link against libxml.so.1 and hope that the libxml developer doesn't break symbol compatibility on me in the 1.X version. Or if you don't care and are reckless, just link to libxml.so and get whatever version there is. Sometimes, when enough people do this, the library author has to get creative with later versions. Hence, libxml2:

lrwxrwxrwx 1 root root     17 Apr  4  2002 libxml2.so.2 -> libxml2.so.2.4.10
-rwxr-xr-x 1 root root 692727 Nov 13  2001 libxml2.so.2.4.10

Note that there's no libxml2.so in this one. Looks like the developer got fed up with irresponsible application developers.