On 7/28/20 12:02 PM, Norbert Preining wrote: > Dear GCC Team, > > (please Cc) > > I would like to ask about how we should deal with gcc10 creating > completely different symbols than what we currently have. > > Are we supposed to bump the ABI version for every library due to the > symbols changes, or is there any other procedure to be expected. > > The announcement of Matthias: >> I'm planning to make gcc-10 the default after gcc-10 (10.2.0) is available >> (upstream targets mid July). binutils will be updated before making the GCC >> switch. The GCC 10 switch involves some minor library transitions for D, >> gccgo, >> M2, which should be no-brainers. The gnat transition will be handled >> separately >> by the debian Ada maintainers. > Doesn't really hint at problems to be expected, but we see considerable > FTBFS due to symbols disappearing. > > Do you have any guideline on how to deal with these cases?
I am not aware of any ABI changes triggered by GCC 10 besides those explicitly and implemented as soname changes for some runtime libraries. If these are C++ symbols, then yes, there's nothing to fix, because there is no differentiation between symbols belonging to the ABI and private symbols like template instantiations, or destructor symbols (see #961469), or symbols depending on the optimization level. Just don't use symbols files for C++. Suggested ways to solve these issues: - Use plain shlibs files, without using symbols files, although debhelper wrongly warns about missing symbols files. - Use a better tool like abi-compliance-checker or abigail, although both are missing dpkg integration like symbols files. I think abi-compliance-checker/dh-acc) isn't actively maintained anymore upstream, so I would suggest to have a look at abigail (abigail-tools). See abipkgdiff(1) for just comparing two package versions (including the dbgsym packages). Instead of adding the abigail information to the packaging, you could also run abigail checks for the migration of packages from unstable to testing. Matthias