On Mon, Aug 7, 2017 at 4:47 PM, <jcowg...@debian.org> wrote: > Package: libzeroc-ice3.6 > Version: 3.6.3-5 > Severity: serious > Tags: sid buster > User: debian-...@lists.debian.org > Usertags: gcc-7-op-mangling > > Hi, > > It appears that your package provides an external symbol that is > affected by the recent name mangling changes in GCC 7. See: > https://gcc.gnu.org/gcc-7/porting_to.html#conversion-op-mangling > > 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. > > To ensure that new executables will pull in the newer version of the > library built with GCC 7: > - Your library package should Build-Depend on g++ (>= 4:7). > Do we really need the version here or is fine to just Build-Depend on g++? I will prefer to not have a version there as currently I share the same control file for several distributions were 4:7 is not available
> - If your package provides a symbols file, ensure that the new > conversion operator symbols have a version matching the version this > bug is fixed in (including the Debian revision and tilde if > necessary). > > Using apt as an example (debian/libapt-pkg5.0.symbols): > (c++)"URI::operator std::__cxx11::basic_string<char, > std::char_traits<char>, std::allocator<char> >[abi:cxx11]()@APTPKG_5.0" > 0.8.0 > + (c++)"URI::operator std::__cxx11::basic_string<char, > std::char_traits<char>, std::allocator<char> >()@APTPKG_5.0" 1.5~beta2~ > > Where "1.5~beta2" is the version this bug was fixed in. > > - If your package does not provide a symbols file, add a dh_makeshlibs > override so that tight enough dependencies are generated. > > Using libebml as an example (debian/rules): > + override_dh_makeshlibs: > + # For new symbols when compiled with GCC 7 > + dh_makeshlibs -V'libebml4v5 (>= 1.3.4-2~)' > > Does this work with dbgsym generated packages? Where "1.3.4-2" is the version this bug was fixed in. > > - If your package is about to be renamed due to an upstream SONAME bump, > you do not need to add any special symbols handling. > > If you would like to know the exact name of the new symbols, using > "abipkgdiff" from abigail-tools might be able to help. > > Thanks, > James > -- José Gutiérrez de la Concha ZeroC, Inc.
