Upgrading GCC/ja

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

はじめに
この記事は、GCCの"アップグレード"についてです. 反対にもしもGCCをダウングレードしたら、望まぬ弊害が起こる危険性があります. また、一般的に報告されている問題のいくつかについては、トラブルシューティングの節を参照してください.

次のセクションでは、GCCのアップグレード（とどのように簡単に彼らは）への迅速なプライマーを提供します. あなたはGCCのアップグレードの背後に長い理由を読みたい場合は、GCCの説明のアップグレードに進んで下さい.

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

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

現在のバージョンを確認し、旧バージョンをアンインストールしましょう:

以上です. 新しいコンパイラで楽しんでください！

はじめに
GCC のアップグレードはいつも謎めかされてきました. というのも、「ほかには何もしなくていいよ」というものから、「システム全体の再ビルドを2度しなければならないよ」というものまで、言われることに幅があるからです. こうした疑念のおおよそは、ABI の互換性にまつわる混乱からきています. しかしまずは、 にまつわることについて軽く指摘しておきます.

libtool と fix_libtool_files.sh
以前は、GCC を Gentoo にインストールした際には という特別なコマンドを実行する必要がありました. 今では、このコマンドの実行はパッケージそのものの展開と一緒に（ toolchain eclassを通じて）自動的に行われるようになりましたから、このコマンド自体を改めて実行する必要はありません.

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

ABI の変化
ABI、あるいはApplication Binary Interfaceは、コンパイラ、アセンブラ、リンカ、そして言語ランタイムサポート(情報源: GCC Binary Compatibility)を含む、プログラムのバイナリ表現を扱うすべてのツールによって使用される規則の集まりです. バイナリアプリケーションやライブラリに使用されているABIが変更されると、C++のコードを用いているすべてのライブラリをビルドしなおすまで、リンカのエラーやプログラムの誤動作が発生する危険性があります.

そう、C++です、ほとんどの非互換はC++ ABIの中で生じるためです. もしあなたがGCC 4.1やGCC5.1へアップグレードした場合、おそらくABIの問題に直面することになるでしょう. これは、私達が (GCC 3からGCC 4.1へのアップグレードの場合)あるいは (GCC 4からGCC 5.1へのアップグレードの場合)に対してを使う理由でもあります.

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

さらなる情報や実例は、以下を見てください：


 * 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

すべてをリビルドすべきか
「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 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:

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.