>
> 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.
boost was in a similar position. it is too much work to maintain
symbols files for it, update them for new upstream releases, or even
just adjust for the new default compiler.
the solution there was to just bump the library soname on every
upstream change, and often bump package name (sort of soft library abi
bump) upon changes to the vendored re-exported libs and/or compiler
induced symbol changes. That works really well for c++. It may be
redundant for some updates, but it is a foolproof way, with single
pass uploads.
--
okurrr,
Dimitri
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
