Bug#871288: libzeroc-ice3.6: requires rebuild against GCC 7 and symbols/shlibs bump

2017-08-09 Thread James Cowgill 
Hi,

On 09/08/17 10:07, Jose Gutierrez de la Concha wrote:
> On Tue, Aug 8, 2017 at 6:07 PM, James Cowgill  > wrote:
> 
>On 08/08/17 11:29, Jose Gutierrez de la Concha wrote:
>> On Tue, Aug 8, 2017 at 5:01 PM, James Cowgill > 
>> >> wrote:
>>[...]
>>>- 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~)'
>>> 
> 
> Any ideas how should I handle multiple packages in override_dh_makeshlibs
> zeroc-ice has several packages that include libzeroc-ice3.6,
> libzeroc-freeze3.6
> so I cannot really pass a single package name in -V 

Here's an example. SFML has 5 libraries and 2 of them have specific
dh_makeshlibs calls.

https://sources.debian.net/src/libsfml/2.4.2%2Bdfsg-4/debian/rules/#L18

In short, you use the -p option to apply a -V to a specific package and
then use --remaining-packages if there are any left.

I think that only the libzeroc-ice3.6 package is affected by this
(although you may want to double check) so you may only need to set the
dependencies for that package.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#871288: libzeroc-ice3.6: requires rebuild against GCC 7 and symbols/shlibs bump

2017-08-09 Thread Jose Gutierrez de la Concha 
Hi James

On Tue, Aug 8, 2017 at 6:07 PM, James Cowgill  wrote:

> On 08/08/17 11:29, Jose Gutierrez de la Concha wrote:
> > On Tue, Aug 8, 2017 at 5:01 PM, James Cowgill  > > wrote:
> > [...]
> > > - 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~)'
> > >
>

Any ideas how should I handle multiple packages in override_dh_makeshlibs
zeroc-ice has several packages that include libzeroc-ice3.6,
libzeroc-freeze3.6
so I cannot really pass a single package name in -V

> > Does this work with dbgsym generated packages?
> >
> > dh_makeshlibs has nothing to do with dbgsym packages. I'm not sure I
> > quite understand your question.
> >
> > As far as I can tell libzeroc-ice3.6 currently does not provide a shlibs
> > or symbols
> > file, so I guess we can skip this for now?
>
> It provides an shlibs file:
> $ dpkg-deb -I libzeroc-ice3.6_3.6.3-5_amd64.deb
>  new debian package, version 2.0.
>  size 1905864 bytes: control archive=1639 bytes.
>  728 bytes,18 lines  control
> 1293 bytes,16 lines  md5sums
>  471 bytes,18 lines   *  postinst #!/bin/sh
>  273 bytes,16 lines   *  postrm   #!/bin/sh
>  398 bytes,12 lines  shlibs
>   60 bytes, 2 lines  triggers
>
> James
>
>

Regards,
José

-- 
José Gutiérrez de la Concha
ZeroC, Inc.

Bug#871288: libzeroc-ice3.6: requires rebuild against GCC 7 and symbols/shlibs bump

2017-08-08 Thread James Cowgill 
On 08/08/17 11:29, Jose Gutierrez de la Concha wrote:
> On Tue, Aug 8, 2017 at 5:01 PM, James Cowgill  > wrote:
> [...]
> > - 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?
> 
> dh_makeshlibs has nothing to do with dbgsym packages. I'm not sure I
> quite understand your question.
> 
> As far as I can tell libzeroc-ice3.6 currently does not provide a shlibs
> or symbols
> file, so I guess we can skip this for now? 

It provides an shlibs file:
$ dpkg-deb -I libzeroc-ice3.6_3.6.3-5_amd64.deb
 new debian package, version 2.0.
 size 1905864 bytes: control archive=1639 bytes.
 728 bytes,18 lines  control
1293 bytes,16 lines  md5sums
 471 bytes,18 lines   *  postinst #!/bin/sh
 273 bytes,16 lines   *  postrm   #!/bin/sh
 398 bytes,12 lines  shlibs
  60 bytes, 2 lines  triggers

James



signature.asc
Description: OpenPGP digital signature

Bug#871288: libzeroc-ice3.6: requires rebuild against GCC 7 and symbols/shlibs bump

2017-08-08 Thread Jose Gutierrez de la Concha 
Hi James,

On Tue, Aug 8, 2017 at 5:01 PM, James Cowgill  wrote:

> Hi Jose,
>
> On 08/08/17 08:07, Jose Gutierrez de la Concha wrote:
> > On Mon, Aug 7, 2017 at 4:47 PM,  > > wrote:
> [...]
> > 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
>
> Firstly, you shouldn't build depend on g++ without a version since it's
> already build-essential.
>
> For Debian, you can probably get away with not adding this dependency if
> you wait some time (say a week?) for all the buildds to update to using
> GCC 7 by default. Doing this is less robust though - for your other
> distributions you will need to remember to do another shlibs bump if you
> do switch to GCC 7.
>
> [...]
> > - 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?
>
> dh_makeshlibs has nothing to do with dbgsym packages. I'm not sure I
> quite understand your question.
>
> As far as I can tell libzeroc-ice3.6 currently does not provide a shlibs
or symbols
file, so I guess we can skip this for now?
>
> Thanks,
> James
>
>
Regards,
José

-- 
José Gutiérrez de la Concha
ZeroC, Inc.

Bug#871288: libzeroc-ice3.6: requires rebuild against GCC 7 and symbols/shlibs bump

2017-08-08 Thread James Cowgill 
Hi Jose,

On 08/08/17 08:07, Jose Gutierrez de la Concha wrote:
> On Mon, Aug 7, 2017 at 4:47 PM,  > wrote:
[...]
> 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

Firstly, you shouldn't build depend on g++ without a version since it's
already build-essential.

For Debian, you can probably get away with not adding this dependency if
you wait some time (say a week?) for all the buildds to update to using
GCC 7 by default. Doing this is less robust though - for your other
distributions you will need to remember to do another shlibs bump if you
do switch to GCC 7.

[...]
> - 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?

dh_makeshlibs has nothing to do with dbgsym packages. I'm not sure I
quite understand your question.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#871288: libzeroc-ice3.6: requires rebuild against GCC 7 and symbols/shlibs bump

2017-08-08 Thread Jose Gutierrez de la Concha 
On Mon, Aug 7, 2017 at 4:47 PM,  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 std::char_traits, std::allocator >[abi:cxx11]()@APTPKG_5.0"
> 0.8.0
>   + (c++)"URI::operator std::__cxx11::basic_string std::char_traits, std::allocator >()@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.

Bug#871288: libzeroc-ice3.6: requires rebuild against GCC 7 and symbols/shlibs bump

2017-08-07 Thread jcowgill 
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).
- 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