Bug#871279: libdolfin2016.2: requires rebuild against GCC 7 and symbols/shlibs bump

2017-08-07 Thread Mattia Rizzolo 
On Tue, Aug 08, 2017 at 02:29:48AM +0800, Drew Parsons wrote:
> It's been sitting in NEW for a month, so it would have been gcc-6 I
> think.  But the upload is to experimental.  I figure we can ignore
> anything in experimental, the symbols will get reset for the new ABI
> when we drop it into unstable.

Right, that would be fine.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#871279: libdolfin2016.2: requires rebuild against GCC 7 and symbols/shlibs bump

2017-08-07 Thread Drew Parsons 
On Mon, 2017-08-07 at 17:44 +, Mattia Rizzolo wrote:
> 
> > dolfin 2017.1 is in the NEW queue, so that upgrade will handle this
> > bug.
> 
> Is the binary you uploaded built with gcc-7?  Otherwise that would
> not fix this bug.

It's been sitting in NEW for a month, so it would have been gcc-6 I
think.  But the upload is to experimental.  I figure we can ignore
anything in experimental, the symbols will get reset for the new ABI
when we drop it into unstable.

Drew

Bug#871279: libdolfin2016.2: requires rebuild against GCC 7 and symbols/shlibs bump

2017-08-07 Thread Mattia Rizzolo 
On Mon, 7 Aug 2017, 6:57 p.m. Drew Parsons,  wrote:

> > - If your package is about to be renamed due to an upstream SONAME
> bump,
> >   you do not need to add any special symbols handling.
> >
>
>
> dolfin 2017.1 is in the NEW queue, so that upgrade will handle this
> bug.
>

Is the binary you uploaded built with gcc-7?  Otherwise that would not fix
this bug.

Bug#871279: libdolfin2016.2: requires rebuild against GCC 7 and symbols/shlibs bump

2017-08-07 Thread Drew Parsons 
On Mon, 07 Aug 2017 15:47:15 +0100 jcowg...@debian.org wrote:
> Package: libdolfin2016.2
> Version: 2016.2.0-5
> 
> 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
> 
...
> 
> - If your package is about to be renamed due to an upstream SONAME
bump,
>   you do not need to add any special symbols handling.
> 


dolfin 2017.1 is in the NEW queue, so that upgrade will handle this
bug.

Drew

Bug#871279: libdolfin2016.2: requires rebuild against GCC 7 and symbols/shlibs bump

2017-08-07 Thread jcowgill 
Package: libdolfin2016.2
Version: 2016.2.0-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).
- 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[abi:cxx11]()@APTPKG_5.0" 0.8.0
  + (c++)"URI::operator std::__cxx11::basic_string()@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~)'

  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