Giters

ome / ome-common-cpp

C++ library providing common and portability functionality for all OME C++ components

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

soname is changing with each new release, even when ABI does not change

carandraug opened this issue · comments

commented

Typically a library would change its soname when its ABI changes. However, libome-common is using its version number as soname:

$ objdump -p /usr/local/lib/libome-common.so* | grep SONAME
  SONAME               libome-common.so.5.4.2
  SONAME               libome-common.so.5.4.2

meaning that any library dependent on it would have to be rebuilt and linked again if ome-common is updated. And in terms of debian packaging, that would mean a new binary package name with each single release.

I am unsure about what's policy in ome-common for changing ABI, but if it's when major version changes, then something like commit e9b805b would do it.

commented

Managing C++ ABIs is difficult, particularly with regard to weak and vague ELF linkage with automatically emitted template instantiations. Several other C++ libraries also avoid soversions, e.g. xerces-c, and historically libapt-pkg. Others like Qt make only limited use of the standard library and templates in their ABIs, which makes soversions easier to support. If you look at the Debian shlibs file maintenance for C++ libraries, you see it's the stuff of nightmares!

At present, with ome-files being pre-1.0, we do not make any hard commitments to ABI stability between releases. The same applies to the API, though we make efforts to not break it by providing compatibility typedefs etc. But we will certainly break it several times before we reach 1.0.

Using proper soversions is certainly something I have thought about, and I would like to support it in the future. But we need to get the API cleaned up alongside the forthcoming OME Files Java before we can do this. And we would also need to get the tooling in place to check and enforce ABI stability to guarantee the versioning is correct. In the meantime, the current versioning strategy is quite intentional; libapt-pkg and several other libraries packaged for Debian use this strategy for the same reasons.

If you have any thoughts about the tools we could use for ABI checking, I would be very interested.

Regards,
Roger