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
> It appears that your package provides an external symbol that is
> affected by the recent name mangling changes in GCC 7. See:
> 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
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
> 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"
> + (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.
José Gutiérrez de la Concha