Bug#985986: marked as done (deprecating/replacing symbols files for C++ libraries)

This is a multi-part message in MIME format...

------------=_1780801142-1244177-0
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

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.)


--=20
985986: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D985986
Debian Bug Tracking System
Contact [email protected] with problems

------------=_1780801142-1244177-0
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Received: (at submit) by bugs.debian.org; 27 Mar 2021 13:33:02 +0000
X-Spam-Checker-Version: SpamAssassin 3.4.2-bugs.debian.org_2005_01_02
	(2018-09-13) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-20.2 required=4.0 tests=BAYES_00,FROMDEVELOPER,
	HAS_PACKAGE,MURPHY_DRUGS_REL8,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,
	TXREP autolearn=ham autolearn_force=no
	version=3.4.2-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 36; hammy, 150; neutral, 75; spammy,
	0. spammytokens: hammytokens:0.000-+--H*F:U*doko,
	0.000-+--H*RU:sk:einhorn, 0.000-+--H*r:sk:einhorn,
	0.000-+--H*r:[email protected],
	0.000-+--Hx-spam-relays-external:sk:einhorn
Return-path: <[email protected]>
Received: from einhorn-mail-out.in-berlin.de ([217.197.80.21]:51935)
	by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <[email protected]>)
	id 1lQ93l-0001uu-R8
	for [email protected]; Sat, 27 Mar 2021 13:33:02 +0000
X-Envelope-From: [email protected]
X-Envelope-To: <[email protected]>
Received: from authenticated.user (localhost [127.0.0.1]) by einhorn.in-berlin.de  with ESMTPSA id 12RDWwv2023824
        (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
        for <[email protected]>; Sat, 27 Mar 2021 14:32:58 +0100
To: Debian Bug Tracking System <[email protected]>
From: Matthias Klose <[email protected]>
Subject: deprecating/replacing symbols files for C++ libraries
Message-ID: <[email protected]>
Date: Sat, 27 Mar 2021 14:32:58 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.7.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Delivered-To: [email protected]

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).

------------=_1780801142-1244177-0
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Received: (at 985986-done) by bugs.debian.org; 7 Jun 2026 02:56:37 +0000
X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02
	(2024-03-25) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-110.5 required=4.0 tests=ALL_TRUSTED,BAYES_00,
	DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FROMDEVELOPER,
	HAS_BUG_NUMBER,SPF_HELO_NONE,SPF_NONE,USER_IN_DKIM_WELCOMELIST
	autolearn=ham autolearn_force=no
	version=4.0.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 34; hammy, 150; neutral, 133; spammy,
	0. spammytokens: hammytokens:0.000-+--Hx-spam-relays-external:36ff,
	0.000-+--H*r:36ff, 0.000-+--H*RT:sk:master., 0.000-+--H*RT:36ff,
	0.000-+--H*RT:216
Return-path: <[email protected]>
Received: from master.debian.org ([2001:41b8:202:deb:216:36ff:fe40:4001]:50924)
	by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
	(Exim 4.96)
	(envelope-from <[email protected]>)
	id 1wW3gj-005DFb-0K
	for [email protected];
	Sun, 07 Jun 2026 02:56:37 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org;
	s=smtpauto.master; h=In-Reply-To:Content-Type:MIME-Version:References:
	Message-ID:Subject:To:From:Date:Reply-To:Cc:Content-Transfer-Encoding:
	Content-ID:Content-Description;
	bh=weMxQ9lZsirHbFELpkYSr+iqoNzZ/l+bnSCHPir0pGk=; b=gYzxOkj5JMZIOFtC3LKYR+U8eN
	UVHNQ7dnMM/ndg50kfhhWK3JyhvmiLbNEwtvNDCzcqwKS8LiiDuMvTlkrwwykJG+uho10bDCsIsUY
	/dUDWiYGjOwdpN32ITmO21iZbeBg9JKWFZjZPxANhDp0dz4oJ7oEqJRji6V+2YEz2A7ma9Z5vcxZz
	FnH+dISTE2/lc9l5gr1MOaVjy1Ogmqx9hCqO7pzPbLuuUVrekxQbSNWM0u/sexYEsL50ENHGliYAr
	VzdYizsU7ZynNyZAuxZ9v+Ho3HWA8IOUklQxu877b2D+5eZOQpGSVY0ANmU1oRSoc+PmJZVMYLkNo
	roXQi1KA==;
Received: from guillem by master.debian.org with local (Exim 4.96)
	(envelope-from <[email protected]>)
	id 1wW3gh-00CXmb-1H;
	Sun, 07 Jun 2026 02:56:35 +0000
Date: Sun, 7 Jun 2026 04:56:34 +0200
From: Guillem Jover <[email protected]>
To: Matthias Klose <[email protected]>, [email protected]
Subject: Re: Bug#985986: deprecating/replacing symbols files for C++ libraries
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email protected]>

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
------------=_1780801142-1244177-0--