[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ubuntu-devel
Subject:    Re: Symbols files for C++ libraries for Ubuntu main
From:       Steve Langasek <steve.langasek () ubuntu ! com>
Date:       2023-06-09 19:10:07
Message-ID: ZIN5D9/rlnelzkoc () homer ! dodds ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi Seb,

On Fri, Jun 09, 2023 at 02:27:02PM +0200, Sebastien Bacher wrote:
> I would like to ask if there is any chance the MIR team would reconsider
> their position on the topic (at least until the day we have a somewhat
> working solution we can use)?

> which also included those types of changes

> - _Znam@Base 2.0~b2-0ubuntu3
> + _Znaj@Base 2.0~b2-0ubuntu4
> +#MISSING: 2.0~b2-0ubuntu4# _Znam@Base 2.0~b2-0ubuntu3

> I personally don't understand why we have those symbols existing on armhf
> which don't exist on amd64. Nor why _Znam@Base is becoming _Znaj@Base nor
> how we are supposed to handle such cases

Passing them through c++filt may help explain:

$ echo _Znam@Base | c++filt 
operator new[](unsigned long)@Base
$ echo _Znaj@Base | c++filt 
operator new[](unsigned int)@Base
$

There are various C++ functions whose signature will change based on the
architecture word length.

.symbols files support various kinds of globbing etc to be able to express
this logically (e.g., you could say '_Zna[mj]@Base' instead of listing two
different symbols as optional), but as you've found, it's an onerous,
iterative process to identify all the ways C++ symbols vary across
architectures and then encode this in a .symbols file.  And in this case,
the symbol isn't part of the library's public ABI anyway, this is just a
function from the base C++ library!

> 4. doing those tweaks need to be done manually since it's not only applying
> the diff but also adding optional keyword at places, I got one wrong and it
> failed to build again

> add one more symbol specific to risvc
> http://launchpadlibrarian.net/647875197/libcupsfilters_2.0~b2-0ubuntu6_2.0~b2-0ubuntu7.diff.gz

Yep.

> I understand the motivation for wanting a symbol file but I agree with what
> Robie, what's the benefit. In that case we spent a few hours to end up with
> a .symbols which as over 150 '(optional)' entries, that doesn't protect us
> much better than just not having a .symbols or using -c0 but still has a
> high cost.

I wouldn't say that it doesn't protect you.  It's a pain to set up initially
and as you note, you can even have to do further fix-ups as a result of
toolchain changes, as the set of template functions and other C++ sugar from
outside of the library that gets exported as ELF symbols can change.  It
DOES have a high cost, but in the end it provides the same level of
protection against accidental ABI breakage as it does for C libraries.

It would be nice to have better consistent tooling around ABI checking for
C++ libraries.  I think the KDE team had some tools around automating the
generation of symbols files - it does require two passes, first to build on
all archs and then to merge the results.  But in principle that's better
than whack-a-mole.

We could also consider using abi-compliance-checker instead of symbols files
for C++ libraries.  There is a dh-acc debhelper addon, but I've never used
it.  We are currently using abi-compliance-checker for the ABI analysis of
armhf for the move to 64-bit time_t; it's unmaintained upstream, but it does
seem to work pretty well - the vast majority of issues we've encountered
with it, when trying to run it over the entire Ubuntu archive, have been due
to header files that #include headers from packages they don't depend on, or
collections of headers that can't all be included together.  Both of these
are issues of much less significance when it's the maintainer doing the
work.  It would require the same sort of two-pass setup process as the KDE
tools, though, and if it has to be done per-arch (probably), it's more
awkward to set up because a-c-c .dump files aren't ascii that you can scrape
from the build logs of failed builds - but it might be a more reliable tool
over the long term than dpkg-gensymbols for C++ libraries.

Downside: symbols files also let you track what version of a package a
symbol was added in, which lets packages' versioned dependencies on
libraries be no stricter than actually necessary.


I don't speak for the MIR team, I have no objection to them relaxing the
requirement of .symbols files for C++ libraries in main.  Just offering some
suggestions on how we can do a better job of automating C++ ABI checks than
we're doing today.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

["signature.asc" (application/pgp-signature)]
[Attachment #6 (text/plain)]

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


[prev in list] [next in list] [prev in thread] [next in thread]