Bug#985986: deprecating/replacing symbols files for C++ libraries
Control: reassign -1 dpkg
On Sat, 27 Mar 2021 14:32:58 +0100 Matthias Klose wrote:
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). [...]
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
[...]
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.
[...]
I see nothing for debhelper to do here as:
1) debhelper is not recommending symbols files for C++ files
2) the proposed alternative methods can be prototyped outside debhelper
as add-ons (and dh-acc seems like it already is) to prove their
meddle in the real world.
Not sure about the dpkg side of things, so I am reassigning it to dpkg
for now in case Guillem wants to add something here.
(Feel free to clone and reassign back if dpkg starts supporting new file
formats / dpkg-X tooling relevant to this)
Thanks,
~Niels
Bug#985986: deprecating/replacing symbols files for C++ libraries
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).
