When I create a library on Linux, I use this method:
- Build: libhelloworld.so.1.0.0
- Link: libhelloworld.so.1.0.0 libhelloworld.so
- 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
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:
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:
Note that there’s no libxml2.so in this one. Looks like the developer got fed up with irresponsible application developers.