SO name is too volatile

[Shachar]

Describe the bug
Building the library on Linux results in a library called libg3log-2.1.0-20 or similar. The problem is that every part of that is part of the SO name. This means that any change to the code at all results in a library that will not link with the previous library.

The result is that it is all but impossible to create binary packages for g3log. It is not feasible to distribute g3log in binary form over time.

To Reproduce

• Build g3log on Linux
• Run objdump -x libg3log.so | grep SONAME

The result is the entire version string.

Additional context
Traditionally, the SONAME should only change when introducing non-backwards compatible changes to the ABI. It should, likely, only include the major version number.

I've submitted a pull request #402 with precisely this change.

[KjellKod]

Hmm. This is the first time I have ever heard about this. I know for a fact that g3log has been packaged and distributed by literally hundreds of companies to date. I'm not saying you are wrong, I'm saying I've never heard about this before and apparently other folks haven't found it an issue worth mentioning.

AFAIK the version number with Major.Minor.BuildVersion is the standard versioning recommendation

You should end up with
libg3log.so
libg3log-2.1.0-20.so which links to the above one.

Please provide some reference as to what the versioning build should be to back up the change.
Please also see the note I added as I don't find any reference so the SOFT_VERSION in Cmake documentation.

[Shachar]

The reason you did not find SOFT_VERSION is that I made it up. I didn't want to completely eliminate the versioning in place. I may have missed something obvious.

[Shachar]

SONAME is used to indicate ABI backwards compatibility. It should only be bumped when a change is introduce that prevents applications compiled with an old version of the library from working if linked with a newer version of the library.

https://en.wikipedia.org/wiki/Soname

It is entirely possible to use the SONAME as a full version information. The practical upshot of doing so is that applications will need to be compiled with the specific version they will later use at runtime. Even a minor deviation will result in linking error.

This makes it completely impractical to package a binary form of the library. What's the point, if I any upgrade to the library requires I recompile all the applications?

I believe that the linking scheme you are referring to is the one used by libtool. Libtool, indeed, uses a three number versioning scheme, and creates an SO with all numbers present in the file name, using symbolic links to bridge the difference. What I believe you are missing, however, is that not all three numbers are used in the SONAME.

https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html#Libtool-versioning

I've created a project that demonstrates how this works.

So if I'm giving libtool the version info 12:57:3 (ABI version 12, backwards compatible 3 versions, this is the 57th iteration inside this version), libtool will create the following files:

-rw-r--r-- 1 shachar shachar 2718 Apr  5 07:27 libsoname.a
-rwxr-xr-x 1 shachar shachar  948 Apr  5 07:27 libsoname.la
lrwxrwxrwx 1 shachar shachar   19 Apr  5 07:27 libsoname.so -> libsoname.so.9.3.57
lrwxrwxrwx 1 shachar shachar   19 Apr  5 07:27 libsoname.so.9 -> libsoname.so.9.3.57
-rwxr-xr-x 1 shachar shachar 8320 Apr  5 07:27 libsoname.so.9.3.57

The SONAME, however, is 9:

$ objdump -x libsoname.so | grep SONAME
  SONAME               libsoname.so.9

To facilitate this, libtool generates a symbolic link from libsoname.so.9 to libsoname.so.9.3.57, which is the only link that matters. The .so link is only needed when I link against the library (i.e. - when I compile). In Debian, the .so.9 and .so.9.3.57 files would be packaged in a deb called libsoname9 (the package's name contains the SONAME, so that multiple versions of the ABI can be installed side by side). The .so file is packaged, along with the .a file and the .la files, in libsoname-dev. This one does not contain the SONAME in the package name, as you only really want to link against the latest version of the library.

[KjellKod]

I believe what we should strive for is the
VERSION being the full complete version number (as before).
The SOVERSION howevever should only be the MAJOR version part.

I.e. See also https://github.com/KjellKod/g3log/blob/c0ae589024e1f1fd851689c6825bbca48a097508/Build.cmake which is what I think is the SOVERSION line that is causing you this issue. The current PR is "fixing" it by hijacking VERSION since that was erroneously used before when creating the SOVERSION in Build.cmake

I think this blog explained the differences well: https://pusling.com/blog/?p=352

Suggested actions:

1. Revert the VERSION change to be as before.
2. Set the SOVERSION property in CMakeLists.txt instead of in the Build.cmake
3. Remove the offending line in Build.cmake

   g3log/Build.cmake

   Line 79 in c0ae589

   SOVERSION ${VERSION}

Potentially a similar line has to exist in Build.cmake but I believe setting the property should be enough. If not it's easy enough to work around in Build.cmake

[KjellKod]

I think that change ^ would give you exactly what you need and this project would be more compliment with the gist of how VERSION and SOVERSION should be used

[Shachar]

Sounds right. So a better change would be to set SOVERSION to MAJOR_VERSION, and leave VERSION as it is today. Do you need me to submit a revised PR?

[KjellKod]

Please do

…

Sent from my iPhone

On Apr 6, 2021, at 10:58 PM, Shachar Shemesh ***@***.***> wrote:  Sounds right. So a better change would be to set SOVERSION to MAJOR_VERSION, and leave VERSION as it is today. Do you need me to submit a revised PR? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[KjellKod]

fully corrected in #404