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;email@example.com When submitting new reports, please tag these:
- Usertags: ftbfs-gcc-5
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.
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 (?). Tracked in 790757.
- 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). Tracked in 790756.
- gnat transition: stay with GCC 4.9, delay for GCC 6.
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 (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++ (>= 5.1.1-20) 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.
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, because the pre GCC 5 libstdc++6 was marked as experimental for c++11. As done with earlier transitions (e.g. 4.8 to 4.9), we ignore these ABI changes.
- Build the library with GCC 5 (a version newer than 5.1.1-20, currently in experimental).
- 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. Library packages still having a c2a suffix should be renamed by replacing the c2a suffix with v5 (libbar1c2a -> libbar1v5).
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. This is the proposed way to do the transition in Debian.
- Remove g++-4.9 from the distribution.
libstdc++ c++11 incompatibilities (4.9 and 5)
In some 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.
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.
Tracked in PR libstdc++/66145 issues.
- 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.
Backporting packages affected by the libstdc++ ABI transition
Packages in jessie-backports are required to be upgradeable to the version in testing. Packages in Jessie use the classic libcxx98 ABI by default thus changes made for the libcxx98 -> libcxx11 transition need to be reverted.
Library packages which have been renamed to have a "v5" postfix must be backported under their pre-transition name (libfoo2v5 -> libfoo2).
Libraries which have been transitioned with a major version change thus avoiding the "v5" postfix (libfoo2 -> libfoo3) need to be changed first in unstable to properly upgrade from their libcxx98 variant by adding the following fields to their control file:
Package: libfoo3 ... Breaks: libfoo3v4 Replaces: libfoo3v4
After this change made it to testing the library can be uploaded to jessie-backports appending "v4" to its name (libfoo3v4) and making sure that it exports the proper ABI.
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.
link errors are usually caused by the new C11 inline semantics. They can be avoid by adding an attribute "attribute ((gnu_inline))" before the inline keyword (preferred method), or by building with -fgnu89-inline (doesn't make sense if headers are installed in -dev packages).
Prepare for GCC 6
While GCC 6 isn't yet released, it is already known that g++ will default to a newer C++ standard (c++11 or c++14). Either prepare packages to build using the newer C++ standard, or explicitly pass -std=c++98 or -std=gnu++98 to the compiler for those package builds.
- 2015-06-15: Raise GCC 5 ftbfs issues to severity important (DONE).
- 2015-06-16: Upload GCC 5 configured for the libstdc++6 dual ABI to experimental (DONE).
- 2015-06-25: Raise severity of GCC 5 issues to serious (except for the ones affecting symbols files) (DONE).
- Fix and upload GCC 5 issues.
- Prepare patches for g++ 5 symbols files.
- Make GCC 5 the default (except for gnat).
- Start the libstdc++6 transition ...
Ubuntu test rebuild results (amd64, i386, arm64, armhf, powerpc, ppc64el).