GCC のアップグレード

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page Upgrading GCC and the translation is 60% complete.

Other languages:
English • ‎español • ‎日本語 • ‎한국어 • ‎русский • ‎中文(中国大陆)‎

この文書では、GCC のアップグレード手順を案内しています。





Short version

GCC をアップグレードしたときには、コンパイラのバージョンを変更することと、libtool を再ビルドすること以外には必要なことはありません:

root #emerge -u sys-devel/gcc
root #gcc-config -l
[1] i686-pc-linux-gnu-4.4.5 *
[2] i686-pc-linux-gnu-4.5.3
root #gcc-config 2
root #env-update && source /etc/profile
root #emerge --ask --oneshot sys-devel/libtool

ただし、GCC を 3.4.0 (3.x 系) や 4.1 より前のバージョンからアップグレードしたときには、 revdep-rebuild も実行する必要があります:

root #revdep-rebuild --library 'libstdc++\.so\.5'

Check the current version and uninstall the old version:

root #gcc --version
root #emerge --ask --depclean =sys-devel/gcc-4.4.5


GCC アップグレードの詳説


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.

ではなぜ、 gcc のバージョンをアップグレードした後には libtool を再ビルドする必要があるのでしょうか? それは、libtool は、プラットフォーム特有のコードを一般化したインターフェイスに集約することで、アプリケーションソフトがプラットフォーム特有の側面を意識することなく共用ライブラリを利用可能にするものだからです。この機能を適切に実現するには、libtool のスクリプトは、様々な場所にある共用ライブラリを見つけ出して、その中にハードコーディングされた gcc のバージョン情報を得なければなりません。

ABI の変化

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).

root #revdep-rebuild --library 'libstdc\+\+.so.6' -- --exclude gcc

So why is this only needed up to GCC 3.4.0/4.1/5.1? That's 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. In that case, the version of the libstdc++.so library will probably be increased.

C++11 (および 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.



「GCC の新たなバージョンを入れたときには、各パッケージのすべてを再ビルドせねばならない」と心に誓っている人もいます。もちろん、そうする意味はありません。なぜなら、ビルドやインストールに GCC を一切使わないアプリケーションソフトもたくさんあり、そうしたソフトウェアには影響がないからです。

そうはいっても、彼らが完全に間違えているかというと、そうでもありません: 新しいバージョンの GCC ではしばしば、プロセッサの命令セットのサポートが向上していることがあります。そうすると、より良い性能が得られるアプリケーションソフトもあるかもしれません。そうした性能の向上は一般的にたかが知れている範囲ですが、ときには(特に CPU に大きく頼っているソフトウェアでは)目立った向上が生み出されることもあります。

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

During updates, you might encounter an error like the following:

CODE GLIBCXX_x.y.z 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

This means that you are trying to build a package with an older GCC version than with which some depending libraries were built. Remember when we told that the C++ ABI is forward-compatible? That is true, 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 previous revdep-rebuild section.

Which packages are known to need a rebuild?

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

See also