6.17.1. GCC のインストール
        
        
          x86_64 上でビルドしている場合は、64ビットライブラリのデフォルトディレクトリ名を「lib」にします。
        
        
case $(uname -m) in
  x86_64)
    sed -e '/m64=/s/lib64/lib/' \
        -i.orig gcc/config/i386/t-linux64
  ;;
esac
        
          GCC のドキュメントによると GCC のビルドにあたっては、専用のビルドディレクトリを作成することが推奨されています。
        
        
mkdir -v build
cd       build
        
          GCC をコンパイルするための準備をします。
        
        
SED=sed                               \
../configure --prefix=/usr            \
             --enable-languages=c,c++ \
             --disable-multilib       \
             --disable-bootstrap      \
             --with-system-zlib
        
          他のプログラミング言語は、また別の依存パッケージなどを要しますが、現時点では準備できていません。 GCC
          がサポートする他のプログラム言語の構築方法については BLFS
          ブック の説明を参照してください。
        
        
          
            Configure パラメーターの意味:
          
          
            - 
              SED=sed
- 
              
                ハードコーディングされているパスを /tools/bin/sed とするために、環境変数を設定します。
               
- 
              --with-system-zlib
- 
              
                このオプションはシステムに既にインストールされている Zlib
                ライブラリをリンクすることを指示するものであり、内部にて作成されるライブラリを用いないようにします。
               
 
        
          パッケージをコンパイルします。
        
        
make
        
          ![[重要項目]](../images/important.png) 
          
            重要項目
          
          
            本節における GCC のテストスイートは極めて重要なものです。 したがってどのような場合であっても必ず実行してください。
          
         
        
          GCC テストスイートの中で、スタックを使い果たすものがあります。 そこでテスト実施にあたり、スタックサイズを増やします。
        
        
ulimit -s 32768
        
          コンパイル結果をテストします。 エラーが発生しても停止しないようにします。
        
        
make -k check
        
          テスト結果を確認するために以下を実行します。
        
        
../contrib/test_summary
        
          テスト結果の概略のみ確認したい場合は、出力結果をパイプ出力して grep -A7 Summ を実行してください。
        
        
          テスト結果については http://www.linuxfromscratch.org/lfs/build-logs/8.0/
          と http://gcc.gnu.org/ml/gcc-testresults/
          にある情報と比較することができます。
        
        
          テストに失敗することがありますが、これを回避することはできません。 GCC
          の開発者はこの問題を認識していますが、まだ解決していない状況です。 特に今行っているように root ユーザーにてテストを実施すると
          libstdc++ に関するテストが5つ失敗します。 上記の URL
          に示されている結果と大きく異なっていなかったら、問題はありませんので先に進んでください。
        
        
          パッケージをインストールします。
        
        
make install
        
          FHS
          の求めるところに応じてシンボリックリンクを作成します。 これは慣例によるものです
        
        
ln -sv ../usr/bin/cpp /lib
        
          パッケージの多くは C コンパイラーとして cc を呼び出しています。
          これに対応するため、以下のシンボリックリンクを作成します。
        
        
ln -sv gcc /usr/bin/cc
        
          リンク時の最適化 (Link Time Optimization; LTO)
          によりプログラム構築できるように、シンボリックリンクを作ります。
        
        
install -v -dm755 /usr/lib/bfd-plugins
ln -sfv ../../libexec/gcc/$(gcc -dumpmachine)/6.3.0/liblto_plugin.so \
        /usr/lib/bfd-plugins/
        
          最終的なツールチェーンが出来上がりました。 ここで再びコンパイルとリンクが正しく動作することを確認することが必要です。
          そこで本節の初めの方で実施した健全性テストをここでも実施します。
        
        
echo 'int main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'
        
          問題なく動作するはずで、最後のコマンドから出力される結果は以下のようになるはずです。
          (ダイナミックリンカーの名前はプラットフォームによって違っているかもしれません。)
        
        
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
        
          ここで起動ファイルが正しく用いられていることを確認します。
        
        
grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
        
          上のコマンドの出力は以下のようになるはずです。
        
        
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../lib/crt1.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../lib/crti.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../lib/crtn.o succeeded
        
          作業しているマシンアーキテクチャーによっては、上の結果が微妙に異なるかもしれません。 その違いは、たいていは /usr/lib/gcc の次のディレクトリ名にあります。 注意すべき重要な点は
          gcc が crt*.o という三つのファイルを /usr/lib 配下から探し出しているということです。
        
        
          コンパイラーが正しいヘッダーファイルを読み取っているかどうかを検査します。
        
        
grep -B4 '^ /usr/include' dummy.log
        
          上のコマンドは以下の出力を返します。
        
        
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/include-fixed
 /usr/include
        
          もう一度触れておきますが、プラットフォームの「三つの組
          (target triplet)」の次にくるディレクトリ名は CPU
          アーキテクチャーにより異なる点に注意してください。
        
        
          ![[注記]](../images/note.png) 
          
            注記
          
          
            GCC のバージョン 4.3.0 では limits.h
            ファイルを無条件に include-fixed
            ディレクトリにインストールします。 したがってそのディレクトリは存在していなければなりません。
          
         
        
          次に、新たなリンカーが正しいパスを検索して用いられているかどうかを検査します。
        
        
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
        
          '-linux-gnu' を含んだパスは無視すれば、最後のコマンドの出力は以下となるはずです。
        
        
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/local/lib64")
SEARCH_DIR("/lib64")
SEARCH_DIR("/usr/lib64")
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");
        
          32ビットシステムではディレクトリが多少異なります。 以下は i686 マシンでの出力例です。
        
        
SEARCH_DIR("/usr/i686-pc-linux-gnu/lib32")
SEARCH_DIR("/usr/local/lib32")
SEARCH_DIR("/lib32")
SEARCH_DIR("/usr/lib32")
SEARCH_DIR("/usr/i686-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");
        
          次に libc が正しく用いられていることを確認します。
        
        
grep "/lib.*/libc.so.6 " dummy.log
        
          最後のコマンドの出力は以下のようになるはずです。
        
        
attempt to open /lib/libc.so.6 succeeded
        
          最後に GCC が正しくダイナミックリンカーを用いているかを確認します。
        
        
grep found dummy.log
        
          上のコマンドの出力は以下のようになるはずです。 (ダイナミックリンカーの名前はプラットフォームによって違っているかもしれません。)
        
        
found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
        
          出力結果が上と異なっていたり、出力が全く得られなかったりした場合は、何かが根本的に間違っているということです。
          どこに問題があるのか調査、再試行を行って解消してください。 最もありがちな理由は、スペックファイルの修正を誤っていることです。
          問題を残したままこの先には進まないでください。
        
        
          すべてが正しく動作したら、テストに用いたファイルを削除します。
        
        
rm -v dummy.c a.out dummy.log
        
          最後に誤ったディレクトリにあるファイルを移動します。
        
        
mkdir -pv /usr/share/gdb/auto-load/usr/lib
mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib