Le 09/06/2023 à 21:10, Steve Langasek a écrit :
> 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.
The difference with C library projects and why I'm saying it doesn't
really protect us is that for a C library the symbols are mostly stable
and I feel like we are able to review the diff when there is a change
and understand if there is an issue.
Where the way we currently maintain our c++ projects symbols in practice
is that we end up listing stack of symbols as optional or just applying
the diff proposed in build log (even if that removes a stack of existing
symbols which could include ABI incompatibilities) because most of us
are not able to make sense of what the tools are outputing.
> 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.
Thanks for the suggestions to you and Dimitry, I will try to at least
summarize the best practices/outcome of the discussion on a wikipage for
those we want to do c++ symbols tracking but are struggling with it.
I will also try to raise the topic more directly to the MIR team during
the weekly meeting because even with the tips shared here I still think
the requirement should be lifted.
Cheers,
Sébastien Bacher
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
