Hey Steve, 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
