Upgrading GCC

Downgrading GCC might have unwanted side effects. Refer to the troubleshooting section for some commonly reported issues.

Quick guide to GCC upgrades
Most GCC upgrades are as simple as switching the compiler version (here from 5.4.0 to 6.4.0) and rebuilding :

Check the current version number and then uninstall the old version:

Enjoy the new compiler!

Extended guide to GCC upgrades
GCC upgrading has always been mystified, with suggestions ranging from "users do not need to do anything" to "users will need to rebuild the entire system twice". The uncertainty was caused by confusion about ABI incompatibility, something that nowadays rarely causes problems.

libtool
The reason we need to rebuild libtool after the upgrade of versions is because of its main purpose: libtool is a toolset that aggregates platform-specific code in a generic interface, allowing applications to build against shared libraries without needing to deal with the platform-specific aspects of shared libraries. To fulfill its function properly, the script uses various library locations that have hard-coded  version information in them.

wxGTK < 3.0.4 applications
If your x11-libs/wxGTK versions are < 3.0.4-r2 (slot 3.0) or < 3.0.4-r302 (slot 3.0-gtk3), this applies to you. (This bug, now obsolete, was fixed in in 2019.)

In such cases, first update your x11-libs/wxGTK. (And if you have dev-python/wxpython, update it too. See below.) Then update all applications that depend on wxGTK. It was necessary because wxGTK applications fixated on minor C++ ABI revisions when gcc versions increase.

ABI changes before gcc-5.1
An ABI (Application Binary Interface), is a set of conventions used by all tools that deal with binary representation of programs, including compilers, assemblers, linkers, and language runtime support (source: GCC Binary Compatibility). When the ABI used for binary applications and libraries is changed, you will risk getting linker errors or malfunctioning programs unless you rebuild all libraries that use C++ code.

If you are upgrading to GCC 4.1, or GCC 5.1, you would probably encounter ABI issues. To prevent this, the command should be run against the  library when moving from GCC 3 to GCC 4.1, or  when moving from GCC 4 to GCC 5.1.

This is only needed till GCC 4.1/5.1 because from that version onward, GCC uses a forward-compatible ABI, which removes the need for rebuilding applications and libraries. Of course, guarantees can never be given indefinitely, but when an incompatibility occurs again, we'll definitely document it here and release a news item. In that case, the version of the library will probably be increased.

The special case C++11 (and C++14)
While GCC (or more specifically, libstdc++) goes to great lengths to guarantee stability of the ABI, this guarantee does not extend to all parts of C++ within libstdc++. Formally, with versions starting from 3.4, GCC/libstdc++ only guarantees C++98/C++03 ABI stability and not more. This is crucial for packages that depend on C++11. GCC only makes C++11 ABI stability guarantees beginning with version 5.1. This means that switching (even minor) versions of gcc (say from 4.7.3 -> 4.7.4) might cause ABI breakage for binaries built from C++11 code.

For more information and some examples, see:


 * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758
 * https://blogs.gentoo.org/blueness/2015/03/10/the-c11-abi-incompatibility-problem-in-gentoo/
 * https://stackoverflow.com/questions/16190269/g-always-backward-compatible-with-older-static-libraries/16196475#16196475
 * https://stackoverflow.com/questions/16190269/g-always-backward-compatible-with-older-static-libraries/16196475#16196475

Which packages are known to need a rebuild?
The following table gives the packages that, if installed, need to be rebuilt and why.

Some collections of packages need to be built with the same compiler (for example, the various packages). Such packages are usually bumped by package maintainers simultaneously, so they will always be built with the same GCC version. Cherry-picking re-installs on these packages might prove to be troublesome.

Rebuilding everything
Some people swear that they need to rebuild every single package on their system when a new GCC version is made available. Of course, that doesn't make sense, since there are many applications that are not using GCC for their build and install process anyhow, so they would never be affected by such changes.

That, however, doesn't mean they are completely incorrect: newer GCC versions often include better support for the processors' instruction set, which might influence the performance of some applications in a positive way.

Apart from such "benign" benefits, rebuilding everything from scratch may be necessary in some cases to fix problems that don't seem to have any obvious cause.

Some software problems are inherently difficult to diagnose and yet could be solved by simply rebuilding one or more appropriate packages. If such a problem has arisen following a GCC upgrade and persists after using the revdep-rebuild approach described above (and after rebuilding any other obviously relevant packages), a complete system rebuild may be the answer.

The "safest" but slowest way to accomplish this is to use the   option of emerge to rebuild the system set and then the world set:

Try this approach before reporting bugs that might have been caused by a GCC upgrade.

rebuild of boost
If needs to be rebuilt, one will get the following error message:

One can rebuild with:

libstdc++.so.6: version `GLIBCXX_3.4.15' not found
During updates, you might encounter an error like the following:

This means that you are trying to build a package with an older GCC version than that with which some depending libraries were built. The C++ ABI is forward-compatible, but it ensures only that higher (or same) GCC versions can be used when building applications and linking libraries (compared to the GCC version used to build those libraries).

To rebuild all the packages depending on libstdc++, see the instructions above.

External resources

 * https://gcc.gnu.org/onlinedocs/gcc.pdf - Using the GNU Compiler Collection PDF.
 * https://gcc.gnu.org/onlinedocs/gccint.pdf - GNU Compiler Collection Internals PDF.