Unexpected soname change within 20210324 branch

[Arfrever]

Difference between abseil-cpp 20210324.0 and 20210324.1 includes:

--- CMake/AbseilHelpers.cmake
+++ CMake/AbseilHelpers.cmake
@@ -263,7 +263,7 @@ Cflags: -I\${includedir}${PC_CFLAGS}\n")
     if(ABSL_ENABLE_INSTALL)
       set_target_properties(${_NAME} PROPERTIES
         OUTPUT_NAME "absl_${_NAME}"
-        SOVERSION "2103.0.0"
+        SOVERSION "2103.0.1"
       )
     endif()
   else()

CMake uses this SOVERSION property to specify arguments passed to linker which specify soname of created library.
When creating some executable/library using some libraries, linker records sonames of used libraries in NEEDED entries in newly created executable/library.

Soname of given library is expected to be changed only when there are incompatible changes in ABI of this library (e.g. deletions of public functions, classes etc.).

When soname of given library is changed, it is necessary to rebuild other packages which have executables/libraries linked against this library.

There were no incompatible changes in C++ API in this release (abseil-cpp 20210324.1) and it seems unexpected that there would be such incompatible changes in future releases within this LTS branch.

Does abseil-cpp guarantee stable API/ABI within given LTS branch?
If yes, then you should reconsider future values of SOVERSION property. One of ways of avoiding ambiguity of what value should be used for SOVERSION property would be to use only major version of abseil-cpp, e.g. SOVERSION "20210324".

[derekmauro]

Does abseil-cpp guarantee stable API/ABI within given LTS branch?

Yes we do have stability within an LTS branch. Incrementing the SOVERSION was an error here, but I don't think this is any action for us to take other than updating our LTS patch process doc to mention this.

[tpgxyz]

@derekmauro Huh? So previous release got soversion set to 0 and now you just bump it for no reason. Are you going to carry current soversion 2103.0.1, increment it or revert it to 0
Fiddling with soversion makes packaing for distribution quite hard, sepecially when RPM generates provides based on shared library soversion:
/usr/lib64/libabsl_bad_optional_access.so.0 -> rpm will generate provides/requires lib64absl_bad_optional_access0 = 20200923.3-1

then
/usr/lib64/libabsl_bad_optional_access.so.2103.0.1 rpm will generate provides/requires lib64absl_bad_optional_access2103.0.1 = 20210324.1

next ?
If you are going to rever soversion to 0 then updating RPM will be a total mess.

[Arfrever]

Some acceptable possibilities:

• Keep soversion 2103.0.1 forever in future 20210324.* versions.
• Revert soversion to 2103.0.0, quickly release 20210324.2 version and declare 20210324.1 version as broken.
• Change soversion to 20210324, quickly release 20210324.2 version and declare both 20210324.0 and 20210324.1 versions as broken.

[derekmauro]

Keep soversion 2103.0.1 forever in future 20210324.* versions.

This was the choice that was made and our documentation was updated to not increment the soversion. Is that acceptable?

[Arfrever]

Yes.

By the way, what scheme of soversion is planned for future LTS branches?

[derekmauro]

YYMM.0.0. If you are wondering why, I found that the MacOS linker expects the first part (YYMM) to fit into 16 bits, so I could not use the full YYYYMMDD.

[Arfrever]

Usually soversion contains only one number.

However GNU linker and ld.so (dynamic linker/loader) consider whole soname, treat it as string (not limited to sequence valid in UTF-8) and do not require that it actually contain any numbers:

$ gcc -shared -o libA.so -Wl,-h,libćśź$'\x80'.so -x c - </dev/null
$ gcc -o test -Wl,-rpath,. -L. -lA -x c - <<<"int main(){}"
$ readelf -d libA.so | grep --text SONAME
 0x000000000000000e (SONAME)             Library soname: [lib期�.so]
$ readelf -d test | grep --text NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [lib期�.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
$ ./test
./test: error while loading shared libraries: lib期�.so: cannot open shared object file: No such file or directory
$ ln -s libA.so libćśź$'\x80'.so
$ ./test
$ 

Since you maybe want to use scheme with 3 numbers, if MacOS linker does not have more unexpected limitations, then maybe you can use YYYY.MM.DD scheme.