GCC-3.3.1 のインストール

推定構築時間:           11.0 SBU
推定必要ディススペース  274 MB

GCC の再インストール

これでGCC と Binutils をテストするのに必要なツール( Tcl, Expect 及び DejaGnu )がインストールされました。 GCC と Binutils の再インストール、それらの新しい Glibc へのリンク、そして、それらをきちんとテストすることが続けられます。 しかし一つ注意することは、これらのテストスイートはホストシステムから提供される正しく機能する擬似ターミナル( PTYs )に強く依存します。 最近では一般的に PTYs は devpts ファイルシステムによって提供されています。 この点でお使いのホストシステムが正しく設定されているかどうか、簡単なテストを行なうことですぐにチェックすることができます。

expect -c "spawn ls"

もしも

The system has no more ptys.  Ask your system administrator to create more.

というメッセージが出るなら、お使いのホストディストリビューションは適切な PTY 運用について設定されていません。 この場合は、問題を解決できるようになるまで GCC と Binutils へのテストは意味がありません。 PTYs をどうやって動かすようにするかについての情報は http://wiki.linuxfromscratch.org/ の LFS Wiki で調べることができます。

三つの GCC tarball (-core, -g++ 及び -testsuite) を全て一つの同じ作業ディレクトリに解凍します。 それらは全て一つの gcc-3.3.1/ サブディレクトリに展開されます。

初めに一つの問題を正し、それから極めて重要な調整をします。

patch -Np1 -i ../gcc-3.3.1-no_fixincludes-2.patch
patch -Np1 -i ../gcc-3.3.1-specs-2.patch

最初のパッチは GCC "fixincludes" スクリプトを無効にします。先に述べましたが、ここでは fixincludes の過程についてのもう少し立ち入った説明をするのが当然でしょう。 普通、GCC fixincludes スクリプトは修正しなくてはいけないヘッダーファイルについて、お使いのホストシステムを調べます。 お使いのホストシステムで修正されなければいけない Glibc のヘッダーファイルを見つけると、それらを修正し、そして GCC 用のインクルードディレクトリに置きます。 それから、後ほど第 6 章で新しい Glibc をインストールしたあと、このインクルードディレクトリはシステムインクルードディレクトリよりも前に調べられます。 GCC がホストシステムからの修正されたヘッダを探すことになり、LFS システムで実際に使われる Glibc のバージョンに間違いなく適合しないものになるでしょう。

最後のパッチは GCC の動的リンカ(通常 ld-linux.so.2 )のデフォルトの場所を変更します。 これはまた GCC の include 検索パスから /usr/include を取り除きます。 インストールのあとにスペックファイルを調整するよりも、今パッチを当てることは、新しい動的リンカが GCC の実際の構築の間に使われることを保証します。 すなわち、構築の間に作成されたすべての最終的な(および暫定的な)バイナリ類が新しい Glibc に対してリンクされることになります。

Important: これらのパッチは構築全体がうまく行くようにするため、とても重要です。パッチをあてるのを忘れないで下さい。

再び別の構築ディレクトリを作ります。

mkdir ../gcc-build
cd ../gcc-build

GCC の構築を始める前に、デフォルトの最適化フラグを書きかえるすべての環境変数を外すことを思いだしてください。

それではコンパイルのために GCC を準備します。

../gcc-3.3.1/configure --prefix=/tools \
    --with-local-prefix=/tools \
    --enable-clocale=gnu --enable-shared \
    --enable-threads=posix --enable-__cxa_atexit \
    --enable-languages=c,c++

新しい設定オプションの意味

パッケージをコンパイルします。

make

この GCC をコンパイルするのに使っているコンパイラは、以前使った GCC のソースと全く同じバージョンのものから構築されたので、ブートストラップターゲットを今使う必要はありません。

Note: GCC テストスイートをここで実行するのは第 6 章で実行することほど重要ではないと考えられることを指摘しておきます。

結果をテストします。

make -k check

-k フラグは、テストスイートを最初の失敗で停止しないで最後まで実行するために使われます。 GCC テストスイートはとても包括的なものなので、いくつかの失敗がつきものです。 テストスイートの大まかな結果のを知るために、このコマンドを実行します。

../gcc-3.3.1/contrib/test_summary | more

あなたの同じような設定について、gcc-testresults メーリングリストに投稿されたものと自分の結果を比較できます。 現在の GCC-3.3.1 が i686-pc-linux-gnu をどのように見るかという事の例は、http://gcc.gnu.org/ml/gcc-testresults/2003-08/msg01612.html を見て下さい。

この結果は以下のものを含んでいることを記しておきます。

* 1 XPASS (unexpected pass) for g++
* 1 FAIL (unexpected failure) for g++
* 2 FAIL for gcc
* 26 XPASS's for libstdc++

g++ で出ている unexpected pass は --enable-__cxa_atexit を使ったからです。 明らかに、GCC によってサポートされる全てのプラットフォームがその C ライブラリで "__cxa_atexit" をサポートをしているわけではないので、このテストはいつも成功するわけではありません。

libstdc++ で出ている 26 の unexpected pass は --enable-clocale=gnu の使用によるもので、これはバージョン 2.2.5 以上の Glibc ベースのシステムでは正しい選択です。 GNU C ライブラリでの基本的なロケールのサポートは、その他の場合に選ばれる "generic" モデル(これらは例えば Newlibc や Sun-libc, 何とかlibc を使っているとしたら当てはまるかも知れません)よりも優先します。 libstdc++ テストスイートは "generic" モデルを期待しているようなので、そのためこれらのテストがいつも成功するわけではありません。

unexpected failuers はしばしば避けられません。GCC の開発者達は普段それらに気がついていますが、まだ修正するに至っていません。 手短に言うと、結果が上の URL にあるものから大きく異なっていない限り、続けても安全です。

それでは最後にパッケージをインストールします。

make install

Note: この時点で、この章の初めの方で行なった完成度テストを繰り返すことを強く勧めます。 the Section called Glibc の"閉じ込め"の節を再び参照し、チェックを繰り返します。もし結果が悪ければ、上述した GCC Specs パッチをあてるのを忘れているというのが最もありそうな原因でしょう。