Differences between revisions 6 and 7
Revision 6 as of 2015-06-16 14:03:31
Size: 7642
Editor: ?MatthiasKlose
Comment:
Revision 7 as of 2015-06-16 14:26:21
Size: 8662
Editor: ?MatthiasKlose
Comment:
Deletions are marked like this. Additions are marked like this.
Line 65: Line 65:
 * change of type in system_error (reported in [[https://bugs.debian.org/784655|#784655]]). std::system_error compiled with gcc 4.9 is not the same type as thrown from the internals of libstdc++.so from gcc 5.  * change of type in system_error (reported in [[https://gcc.gnu.org/PR66145|PR66145]], first seen in [[https://bugs.debian.org/784655|#784655]]). std::system_error compiled with gcc 4.9 is not the same type as thrown from the internals of libstdc++.so from gcc 5.
  * Packages, which may be affected (https://codesearch.debian.net/perpackage-results/catch.*%3A%3Afailure/2/page_0), although there are false positives like libc++, gcc-h8300-hms):
  * antlr aqsis assimp bitcoin blockattack boo boost1.54 boost1.55 brlaser c++-annotations chromium-browser clustalx cython davix dballe dff diet digikam emscripten ergo fceux flush freefem++ freeorion fslview fw4spl fwbuilder gazebo getfem++ git-crypt gmsh gnote gnudatalanguage healpy innoextract insighttoolkit4 libdap libkolabxml libpqxx libreoffice librime libsbml libwibble lightspark litecoin marisa mira mongodb ncbi-blast+ odb ogre-1.8 ogre-1.9 openscad openwalnut passepartout pdf2djvu photoprint plastimatch plee-the-bear povray powertop psi4 pytaglib realtimebattle ruby-passenger schroot sqlitebrowser tecnoballz thermald wesnoth-1.12 widelands wreport xflr5 xmltooling xsd.
  * Proposed solution: Add versioned breaks in libstdc++6 for packages built with g++-4.9.

Update to GCC 5

GCC 5 was released in April 2015, and is available in Debian unstable. There are again the usual quirks with new standards versions and older software, and as a major change, the update / introduction of a new libstdc++ ABI.

Two test rebuilds of Debian testing/unstable on amd64 were done in January and April, and bug reports filed for the packages. These issues are tracked in http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-5;users=debian-gcc@lists.debian.org When submitting new reports, please tag these:

Two other test rebuilds were done in Ubuntu in February and April, covering other architectures than amd64. See the links at the bottom of the page.

TODO list

  • Fixing GCC build failures.

  • Use GCC 5 by default.
  • GFortran transition (new module version). In the past this was handled by the debian-science team (?).
  • Go transition (easy, no packages relying on gccgo-4.9).
  • GCJ transition (easy, a handful of dependencies).
  • libstdc++ ABI transition (see below in separate section).

libstdc++ ABI transition

The good news is, that GCC 5 now provides a stable libcxx11 ABI, and stable support for C++11 (GCC version before 5 called this supported experimental). This required some changes in the libstdc++ ABI, and now libstdc++6 provides a dual ABI, the classic libcxx98 ABI, and the new libcxx11 (FIXME: GCC 5 (<< 5.1.1-20) only provides the classic libcxx98 ABI). The bad news is that the (experimental) C++11 support in the classic libcxx98 ABI and the new stable libcxx11 ABIs are not compatible, and upstream doesn't provide an upgrade path except for rebuilding. Note that even in the past there were incompatibilities between g++ versions, but not as fundamental ones as found in the g++-5 update to stable C++11 support.

Using different libstdc++ ABIs in the same object or in the same library is allowed, as long as you don't try to pass std::list to something expecting std::cxx11::list or vice versa. We should rebuild everything with g++-5 (once it is the default). Using g++-4.9 as a fallback won't be possible in many cases.

libstdc++ doesn't change the soname, provides a dual ABI. Existing C++98 binary packages will continue to work. Building these packages using g++-5 is expected to work after build failures are fixed. FIXME: Will they only work when built with _GLIBCXX_USE_CXX11_ABI set to 0? By default they will use the new libstdc++ ABI.

GCC 6 is expected to change the c++ standard default to c++11 or c++14, so either prepare these packages for the new standard, or explicitly pass -std=c++98.

Library packages built using -std=c++0x or -std=c++11 may have an ABI change (unknown yet how many). How to find out about these?

  • Build the library with GCC 5 (a version newer than 5.1.1-11).
  • If the library exports some symbols having either _cxx11 or B5cxx11 in the symbol name, it may be incompatible, if these are symbols which form part of the public API. To find out if these are part of the public API, you would need to build all reverse dependencies and see if any of these new symbols are referenced.
  • To be conservative, you want to assume that the library is incompatible, if you find any of these _cxx11 or B5cxx11 symbols.

If the library is incompatible, rename the package, append "v5" to the name of the package (e.g. libfoo2 -> libfoo2v5). Such a change can be avoided, if you have a soversion bump and you upload this version instead of the renamed package.

Instead of renaming, a library could support ABI coexistence like libstdc++ itself (maybe some upstreams will do that, nothing to do on the packaging level).

To build code with gcc-5 which is compatible with the old ABI, define the macro _GLIBCXX_USE_CXX11_ABI to 0 before including any C++ standard library headers. Should only be used for leaf packages, not for libraries as a last resort.

The notes from Fedora describe this issue more in depth (however the incompatibilities between the experimental 4.9 c++11 support and the stable 5 libcxx11 ABI is not addressed).

Roadmap for libstdc++

The goal is to have a dual ABI libstdc++, defaulting to the libcxx11 ABI, building everything using g++-5, and then removing g++-4.9 from the distribution.

  • GCC 5 is now (5.1.1-11) configured with --disable-libstdcxx-dual-abi --with-default-libstdcxx-abi=c++98. This is the configuration where the fewest incompatibilities between the experimental c++11 support and the now stable libcxx11 support are seen. However this configuration doesn't help with the preparation of symbols files with the targeted configuration (--with-default-libstdcxx-abi=c++11).
  • Start fixing build failures without changing the default compiler. This should be possible for everything except for symbols files. For symbols files, make two builds one with the GCC 5 found in testing/unstable, and one with the GCC 5 found in experimental (>= 5.1.1-20). Alternatively do both builds with the compiler found in experimental, one with -D_GLIBCXX_USE_CXX11_ABI=0, and one with D_GLIBCXX_USE_CXX11_ABI=1, and prepare the symbols file (maybe by adding a second file, or marking the symbols as optional).

  • Make GCC 5 the default compiler, maybe tighten the dependency of build-essential on g++, make sure that every buildd has the new version.
  • Depending on which libstdc++ ABI is configured as default:
    • If the libcxx98 ABI is the default, that would be a two step transition, changing the default in GCC again, requiring changes again. Fedora chose this way to handle the transition in time for their next release.
    • Defaulting to the libcxx11 ABI makes this a single transition. OpenSUSE is currently going this way.
  • Remove g++-4.9 from the distribution.

libstdc++ c++11 incompatibilities (4.9 and 5)

In many (?) cases, there are a few ... Upstream's position is, if C++11 from GCC 5 is used, then compiling with GCC 5 and linking to libstdc++.so from GCC 5 is needed (note that this is not the case in unstable, g++-4.9 is used to build, and link with libstdc++ from GCC 5).

  • Passing std::list to something expecting std::cxx11::list or vice versa.

  • change of type in system_error (reported in PR66145, first seen in #784655). std::system_error compiled with gcc 4.9 is not the same type as thrown from the internals of libstdc++.so from gcc 5.

    • Packages, which may be affected (https://codesearch.debian.net/perpackage-results/catch.*%3A%3Afailure/2/page_0), although there are false positives like libc++, gcc-h8300-hms):

    • antlr aqsis assimp bitcoin blockattack boo boost1.54 boost1.55 brlaser c++-annotations chromium-browser clustalx cython davix dballe dff diet digikam emscripten ergo fceux flush freefem++ freeorion fslview fw4spl fwbuilder gazebo getfem++ git-crypt gmsh gnote gnudatalanguage healpy innoextract insighttoolkit4 libdap libkolabxml libpqxx libreoffice librime libsbml libwibble lightspark litecoin marisa mira mongodb ncbi-blast+ odb ogre-1.8 ogre-1.9 openscad openwalnut passepartout pdf2djvu photoprint plastimatch plee-the-bear povray powertop psi4 pytaglib realtimebattle ruby-passenger schroot sqlitebrowser tecnoballz thermald wesnoth-1.12 widelands wreport xflr5 xmltooling xsd.
    • Proposed solution: Add versioned breaks in libstdc++6 for packages built with g++-4.9.
  • Throwing a std::string across module boundaries will have similar issues if the two modules don't use the same std::string because the throw throws one type, and the catch names a different type.
  • New implementation of std::string, using the small string optimization instead of copy-on-write reference counting.

Porting help

General porting help https://gcc.gnu.org/gcc-5/porting_to.html

Add pointers to porting efforts of other distributions (e.g. Fedora, OpenSUSE underway).

Add porting recipes here.

Timeline

TBD

Further information

Ubuntu test rebuild results (amd64, i386, arm64, armhf, powerpc, ppc64el).