Re: libstdc++ follow-up transitions
On Mon, Aug 17, 2015 at 12:07 PM, Matthias Klose <doko@debian.org> wrote:
> Unstable now has GCC 5 as the default for more than two weeks. The follow-up
> transitions are in progress, however the list of transitions at [1] is not
> exhaustive, because this only covered libraries without dependencies on
> libraries which need a transition. There is now another test rebuild [2] done
> with an augmented dh_makeshlibs printing cxx11 symbols in libraries [3]. No new
> bug reports were filed yet.
>
> There seems to be a tendency to avoid transitions, where Debian doesn't have any
> reverse dependencies, or where developers analyze the library API's and come to
> the conclusion that no transition is necessary. I'm not yet sure if this is the
> safest way forward, given the alternative of semi-automatic renaming of the
> packages.
>
> As an example (no pun intended): for libsigc++-2.0 the maintainer assessed that
> the one change wouldn't have any impact. However after a non-change rebuild,
> some binaries started crashing (e.g. aptitude). The problem here is that you
> don't see every ABI change from just looking at the symbols files, which doesn't
> show subtype changes. One way to find out about these is to look at the debug
> information (which is not always available), and compare the old and the new
> package. Tools to do this are abi-compliance-checker and libabigail (you need
> the one in unstable).
Please notice that sadly abi-compliance-checker is not anymore
devellopped and upstream site will be going to rot. I dream that
jenkins jobs could be run for checking ABI at unstrable step.
I avoided a lot of pain for libmagick++ and a few other package (lcms
for instance break the ABI a few time)
Bastien
> abipkgdiff \
> --d1 libsigc++-2.0-0c2a-dbgsym_2.4.0-1_amd64.ddeb \
> --d2 libsigc++-2.0-0v5-dbgsym_2.4.1-2_amd64.ddeb \
> libsigc++-2.0-0c2a_2.4.0-1_amd64.deb \
> libsigc++-2.0-0v5_2.4.1-2_amd64.deb
>
> Looking at the attached output of this run, you'll see that the size of some
> subtypes changed, and that the offset of an unchanged member of a subtype change
> which lead to the crashes at least for aptitude. Still the question is, if you
> want to analyze all libraries using these tools.
>
> Another change for GCC 5 are the destructor symbols (ending in D[012]ev), which
> now get optimized, and are not emitted anymore, where no virtual base classes
> are involved. It should be safe to remove these from the symbols files (or
> marking these as optional).
>
> Matthias
>
> [1]
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libstdc%2B%2B-cxx11;users=debian-gcc@lists.debian.org
> [2] https://people.debian.org/~doko/logs/gcc5-20150813/archive-gcc-08-13-2015/
> [3] deb https://people.debian.org/~doko/tmp/gcc-5 ./
Reply to: