Upgrading from gcc-4.x to gcc-5.x

This article Article description::deals with instructions for upgrading systems from GCC 4.x to GCC 5.x. It has been deprecated in favor of the more modern Upgrading GCC article.

Critical news
The following (GLEP 42) message has been sent to inform users about the important changes.

Title: GCC 5 Defaults to the New C++11 ABI Author: Mike Frysinger  Content-Type: text/plain Posted: 2015-10-22 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: >=sys-devel/gcc-5 GCC 5 uses the new C++ ABI by default. When building new code, you might run into link time errors that include lines similar to: ...: undefined reference to '_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17' Or you might see linkage failures with "std::__cxx11::string" in the output. These are signs that you need to rebuild packages using the new C++ ABI. You can quickly do so by using revdep-rebuild (from gentoolkit). For gentoolkit-0.3.1 or higher: For previous versions of gentoolkit: For more details, feel free to peruse: https://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ https://blogs.gentoo.org/blueness/2015/03/10/the-c11-abi-incompatibility-problem-in-gentoo/
 * 1) revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc
 * 1) revdep-rebuild --library 'libstdc\+\+\.so\.6' -- --exclude gcc

C++ changes
In order to be compliant with the C++11 standard, a number of standard template library (STL) types needed to be changed (specifically std::string and std::list in libstdc++). For backwards compatibility the SONAME of libstdc++.so was not bumped, instead, inline namespaces in combination with ABI tags are used now. These necessitate a recompilation of all C++ code, otherwise code crossing file interface boundaries could fail with

undefined references to std::__cxx11
It is not a bug, if packages fail with undefined references to std::__cxx11 or [abi:cxx11] like

cmGlobalGenerator.cxx:(.text+0x12781): undefined reference to `Json::Value::Value(std::__cxx11::basic_string const&)'

It means you need to rebuild the package that provided that symbol first. See https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html for more info.

Instructions by the GNU project

 * https://gcc.gnu.org/gcc-5/porting_to.html Porting to GCC 5

C changes
A significant change of GCC 5 was the move from  to   as default C standard. Many packages in the tree have implicitly relied on the C standard being  and now fail with different types of errors:

Missing symbol ( emits an externally visible definition,   does not): x86_64-pc-linux-gnu-gcc -Wl,-O1 -Wl,--as-needed background.o list.o main.o notes.o options.o savegeom.o -lpangoxft-1.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype -lXft -lXrender -lX11 -lXrandr -lXext -o xnots main.o: In function `processConfigureNotify.part.3': main.c:(.text+0x133): undefined reference to `resetNoteWidth' savegeom.o: In function `getGeometryFromList':

Redefinition (permitted by ): argp-eexst.c:(.text+0x0): multiple definition of `argp_usage' ../../lib/libmisc.a(argp-help.o):argp-help.c:(.text+0x3590): first defined here ../../lib/libmisc.a(argp-eexst.o): In function `_option_is_short':

The simplest fix for both cases is restoring pre-GCC 5 inline semantics, i.e., inheriting  and adding   to the CFLAGS variable:

This will lead to the same C language behavior as with GCC 4.9 and below.

Bugzilla entries about gcc-5.3

 * the Tracker bug (gcc-5) GCC 5 porting
 * Open Bugzilla entries regarding gcc-5.3