On Mon, Aug 17, 2015 at 12:07 PM, Matthias Klose <d...@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-...@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 ./