Package: dpkg,debhelper
[ Starting this as a discussion, I have no proposal or even patches yet ]
The current practice of checking for ABI compatibility of C++ shared libraries
is a bit cumbersome, and it's often not clear for package maintainers, which
symbols make an ABI, and belong into the symbols file (references to
destructors, vtables, instantiated symbols). We have work-arounds of marking
such symbols as optional, but these are all marked on an ad-hoc basis when these
are not found for a failing build. Symbols also may disappear when building
libraries with a different baseline, or with different optimization options
(e.g. with -O3, or with -flto). I haven't checked if symbols also differ with
the use of different compilers.
There are at least two other tools which seem to be better suited for such
checks:
- abi-compliance-checker, dh-acc, maintained by Google,
last release 2018
- libabigail, maintained by Red Hat, last release 2021
I might be biased with libabigail, maintaining the package in Debian, and adding
the .deb support upstream in addition to the existing rpm support.
The idea would be to have a libfooN.symbols.{acc,abigail} file and then use that
information to generate a symbols file, and automagically adding all "other"
symbols that exist and marking these as optional.
Another scenario could be the use of a libfooN.abigail to directly base the
generation of dependencies on the provided ABI information, and using these ABI
descriptions as a replacement for a symbols file.
A check unrelated to the build time of a package could be a britney check to run
abipkgdiff(1) on package versions from the testing and unstable sources
(assuming that the dbg packages are also available).
