这篇文章讲述 升级 GCC。GCC降级可能会有不愿看到的副作用。对于一些报告中常见的问题请查阅故障排除一节。
emerge -u sys-devel/gcc
 i686-pc-linux-gnu-4.4.5 *  i686-pc-linux-gnu-4.5.3
env-update && source /etc/profile
emerge --ask --oneshot sys-devel/libtool
If you upgrade GCC from a version earlier than 3.4.0 (for the 3.x series) or 4.1, you will need to run revdep-rebuild as well:
revdep-rebuild --library 'libstdc++\.so\.5'
Check the current version and uninstall the old version:
emerge --ask --depclean =sys-devel/gcc-4.4.5
GCC upgrading explained
GCC upgrading has always been mystified, with suggestions ranging from "You do not need to do anything" up to "You will need to rebuild your entire system twice". Most of this fear, uncertainty and doubt comes from the confusion surrounding ABI incompatibility. But first a quick pointer towards libtool.
libtool 和 fix_libtool_files.sh
Earlier installments of GCC on Gentoo required you to run a specific command called fix_libtool_files.sh. Some time ago, the execution of this command has been integrated in the package deployments itself (through the toolchain eclass) so there is no need for users to call this themselves anymore.
The reason we need to rebuild libtool after the upgrade of gcc 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 libtool script uses various library locations that have hard-coded gcc version information in them.
An ABI, or 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.
Yes, C++, since most incompatibilities occur within the C++ ABI. If you are upgrading to GCC 4.1, or GCC 5.1, you would probably encounter ABI issues. This is also why we use the revdep-rebuild command against the libstdc++.so.5 (from GCC 3 to GCC 4.1), or libstdc++.so.6 (from GCC 4 to GCC 5.1).
revdep-rebuild --library 'libstdc\+\+.so.6' -- --exclude gcc
那么为什么只有升级到GCC 3.4.0/4.1/5.1版本才需要这么做？这是因为在这之前的版本，GCC采用向下兼容的ABI，这使得你不需要重新编译软件和系统库。当然，我们不能永远保证这种兼容性。如果发生不兼容的情况，libstdc++.so 库将很可能也会升级到更高的版本。
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:
- bug #513386
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. Although it is expected that this improvement is generally only marginal, in some cases (especially CPU intensive applications) this might yield notable improvements.
There are also known cases where packages need to be built with the same compiler. Although these packages are usually bumped by package maintainers simultaneously (so that they are always built with the same GCC version) cherry-picking re-installs on these packages might prove to be troublesome. The various qt-* packages are a nice example on this matter.
libstdc++.so.6: version `GLIBCXX_3.4.15' not found
cmake_bootstrap_28021_test: /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/libstdc++.so.6: version `GLIBCXX_3.4.11' not found
To rebuild all the packages depending on libstdc++, see the previous revdep-rebuild section.
The following table gives the packages that, if installed, need to be rebuilt and why.
|Package||Rebuild needed because ...|
|sys-devel/libtool||libtool application has hardcoded paths towards GCC internal libraries|
|sys-devel/llvm||depends on exact gcc version, may encounter linking errors with other ebuilds making use of LLVM (e.g. media-libs/mesa) if not rebuilt|