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.

Reply via email to