snappy 1.2.0 removed __ZN6snappy11RawCompressEPKcmPcPm from libsnappy

[ryandesign]

Thank you for opening the issue tracker!

MacPorts recently updated to snappy 1.2.0 and @justinbb reported to us today that snappy 1.2.0 removes a symbol which existed in 1.1.10. The user discovered this by trying to run qgis3 after updating snappy to 1.2.0:

Symbol not found: __ZN6snappy11RawCompressEPKcmPcPm
Referenced from: <6B4C63E9-F153-35F2-B6E3-9B70D5205EB7> /opt/local/lib/libleveldb.1.23.0.dylib
Expected in:     <21F5B8CD-DE83-3E89-BC9F-C6F6CD66E239> /opt/local/lib/libsnappy.1.1.10.dylib

The versioning of libsnappy from snappy 1.2.0 on macOS as installed by MacPorts was:

% otool -L /opt/local/lib/libsnappy.1.dylib
/opt/local/lib/libsnappy.1.dylib:
	/opt/local/lib/libsnappy.1.dylib (compatibility version 1.0.0, current version 1.1.10)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1200.3.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)

The library current version of 1.1.10 was a mistake corrected in #178. After applying that fix, the versioning is now:

% otool -L /opt/local/lib/libsnappy.1.dylib
/opt/local/lib/libsnappy.1.dylib:
	/opt/local/lib/libsnappy.1.dylib (compatibility version 1.0.0, current version 1.2.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1200.3.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)

Translating, this means that you are providing minor version 1.2.0 of major version 1 of libsnappy and it claims it is backward compatible with all minor versions of major version 1 of the library back to version 1.0.0. In other words, if I compiled a program against libsnappy major version 1 minor version 1.0.0, that program should still work if the runtime version of libsnappy is major version 1 minor version 1.2.0. But the failure to launch qgis3 due to the removed symbol shows that claim is not accurate.

Isn't it customary that removing a public symbol from a library would be accompanied by increasing its major version? In other words, snappy 1.2.0 should have included libsnappy.2.dylib not libsnappy.1.dylib. This would have clearly communicated (via a message that libsnappy.1.dylib could not be found when opening a program linking with that library) that everything linking with the library needed to be rebuilt to remove any references to the removed symbol(s).

Caveat: if __ZN6snappy11RawCompressEPKcmPcPm was a private symbol that nobody should have been using, then the above does not apply and the fault would lie with whoever used your private symbol and should be solved by them not using that private symbol.

The problem is also mentioned at apache/arrow#41058 which refers to conda-forge/snappy-feedstock#35 which points the blame for the ABI break on 766d24c.

As an alternative to increasing the major library version to indicate the compatibility break, you could reinstate the removed symbol to restore compatibility and avoid the need to increase the major library version; if possible, this would be the least disruptive solution.

[ryandesign]

you could reinstate the removed symbol to restore compatibility […] this would be the least disruptive solution

If you do this, you would also want to increase the compatibility minor version (the number you pass in the -compatibility_version flag) to 1.2.0 (from its current value of 1.0.0). After all, any program linked with library major version 1 minor version 1.2.0 or later will not run with library major version 1 minor versions earlier than 1.2.0 since they do not have the new __ZN6snappy11RawCompressEPKcmPcPmNS_18CompressionOptionsE symbol.

[danilak-G]

We discussed a bit. We will restore the symbols in 1.2.1. Usually all Google libraries support strong API compatibility with no promise of ABI https://abseil.io/about/compatibility. We understand from the long history of snappy that it created a case where enforcing will create more problems

[danilak-G]

https://github.com/google/snappy/releases/tag/1.2.1

[ryandesign]

Thanks!