推定構築時間: 11.0 SBU 推定必要ディススペース 274 MB |
これで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++ |
新しい設定オプションの意味
--enable-threads=posix: このオプションはマルチスレッドコードのための C++ 例外処理を有効にします。
--enable-__cxa_atexit: このオプションはローカルスタティックとグローバルオブジェクトのデストラクタを登録するのに atexit ではなく __cxa_atexit を使うようにさせ、完全に標準準拠の処理とするのにとても重要です。 これはまた、C++ ABI にも影響し、その結果 C++ 共有ライブラリと C++ プログラムは他の Linux ディストリビューション間で共通に利用できるようになります。
--enable-clocale=gnu: このオプションはあらゆる状況下に置いて C++ ライブラリへの正しいロケールモデルが選ばれるようにします。 設定スクリプトがインストールされた de_DE ロケールを見つけると、gnu の正しいモデルを選択します。 しかし、de_DE ロケールをインストールしない人たちは、間違って generic ロケールモデルが選択されるために、ABI 互換性のない C++ ライブラリを構築する危険を冒すことになります。
--enable-languages=c,c++: このオプションは 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 パッチをあてるのを忘れているというのが最もありそうな原因でしょう。