Your message dated Sun, 7 Jun 2026 04:56:34 +0200
with message-id <[email protected]>
and subject line Re: Bug#985986: deprecating/replacing symbols files for C++
libraries
has caused the Debian Bug report #985986,
regarding deprecating/replacing symbols files for C++ libraries
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
985986: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985986
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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).
--- End Message ---
--- Begin Message ---
Hi!
On Sat, 2021-03-27 at 14:32:58 +0100, Matthias Klose wrote:
> [ 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).
When I looked into this for a thread on debian-devel, it didn't seem
like abigail would be a great candidate for this, see
<https://lists.debian.org/debian-devel/2025/09/msg00203.html> and
further replies.
I think something that might help would be to try to integrate
properly several of the modifications done by the KDE team back into
dpkg, but some of those require generalizing and better toolchain
integration, etc.
As it is, I'm not seeing much path forward for this proposal, so I'm
going to close it for now. If a better plan comes up, please feel free
to reopen or file a new report.
Thanks,
Guillem
--- End Message ---
