Hi, On 08/08/17 15:44, David Kalnischkies wrote: > On Mon, Aug 07, 2017 at 03:47:15PM +0100, jcowgill@debian.org wrote: >> In GCC 7, the name mangling for C++ conversion operators which return a >> type using the abi_tag attribute (most commonly std::string) has >> changed. When your library is compiled with GCC 7, it will now emit two >> symbols for the conversion operator using the new and old naming. >> Executables compiled with GCC 7 will always use the new symbol, while >> old executables compiled using <= GCC 6 will use the old symbol. For new >> executables to build without undefined references, your library will >> need rebuilding with GCC 7. > > On the upside, going through the list of severity pushes [0] I can spot > only aptitude from our reverse build-dependencies – and while it is > indeed using that API, it will stop doing so in the next upload > (#853316) so the practical effect is rather low (assuming we can > convince mafm to upload before we do I guess). > > On a more theoretical note isn't there some way to emit a function with > the old mangle calling the new mangle (or duplicating it)? > I can't really believe that all of libstdc++6 doesn't contain a single > abitagged conversion operator, so I would presume they managed to pull > it of somehow (or we would be looking at v7 everywhere now). Maybe I misunderstood your question, but if you compile a library exporting an affected conversion operator using GCC 7, GCC will emit an alias to ensure that the old and new symbols both work. This is why there is no ABI break here - we just need to ensure these libraries are rebuilt. libstdc++6 doesn't need a workaround here. It doesn't need to build-depend on gcc-7 because it's built from the same source. Beyond that it added the new symbols to the symbols files like any other package. Thanks, James
Attachment:
signature.asc
Description: OpenPGP digital signature