Release 21.3 broke ABI, ironically because of #10271

[Vogtinator]

What version of protobuf and what language are you using?
Version: v21.2 -> v21.3
Language: n/a

What operating system (Linux, Windows, ...) and version?
openSUSE Tumbleweed

We updated protobuf from 21.2 to 21.3 (21.4 should be affected the same way) and multiple applications/libraries stopped working due to this error:

/usr/sbin/usbguard-daemon: symbol lookup error: /lib64/libusbguard.so.1: undefined symbol: _ZN6google8protobuf8internal16InternalMetadataD1Ev

It appears like as a side effect of #10271, the symbol is now completely missing, but libraries/applications build against the previous version still depend on it. This requires a SOVER bump.

CC @pitrou @fowles @coryan

[fowles]

Protobuf does not offer ABI stability. Simply put C++ is actively adversarial to it. That fix was accept to make DEBUG/NDEBUG have similar ABI when built together, but even that level of conformance is best effort only.

[Vogtinator]

Protobuf does not offer ABI stability.

That is not an issue by itself, but you must bump the sover on each relevant change.

[fowles]

Can you look in the build process for where we set the sover? The easiest answer might be to bump it for every release

[dirkmueller]

please reopen :)

[Vogtinator]

FWICT it's set here, in the slightly odd libtool version format (https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html#Libtool-versioning):

protobuf/src/Makefile.am

Line 21 in 53f7830

PROTOBUF_VERSION = 32:4:0

It might be appropriate to switch over to the -release style of library versioning, which could just include the version number: https://www.gnu.org/software/libtool/manual/html_node/Release-numbers.html

[jengelh]

Simply put C++ is actively adversarial to it.

Some projects change their exported symbol set at the flick of ./configure --disable-something, or change a struct's layout as a result of such switch, making any two builds of the same version on the same platform already incompatible, irrespective of the language being used for the project.

[scpeters]

Can you look in the build process for where we set the sover? The easiest answer might be to bump it for every release

it may be easiest to bump for every release, but it does invalidate existing binaries, which has a cost in hours of package manager effort and environmental impact of potentially avoidable CPU time to rebuild binaries. See also #13238

[jengelh]

which has a cost in hours of package manager effort and environmental impact of potentially avoidable CPU time

Looking at dependency lists (244 direct pkgs triggered by protobuf change in openSUSE), build times and core counts, I put the number at around 340 kWh Wh. If that's an incentive not to break the ABI, I'm all for it :-)

[dirkmueller]

Looking at dependency lists (244 direct pkgs triggered by protobuf change in openSUSE), build times and core counts, I put the number at around 340 kWh. If that's an incentive not to break the ABI, I'm all for it :-)

I think that estimate is far too high, but even if it was a good estimate, I would prefer it over packages and users diagnosing manually issues caused by abi breakage.

[jengelh]

Thanks, I found a bug in the unit. (kWh -> Wh)