ii. ツールチェーンの技術的情報

クロスコンパイルについて

クロスコンパイルには必要な捉え方があって、それだけで 1 つの節を当てて説明するだけの価値があるものです。 初めて読む方は、この節を読み飛ばしてかまいません。 ただしビルド過程を十分に理解するためには、後々この節に戻ってきて読んで頂くことをお勧めします。

ここにおいて取り上げる用語を定義しておきます。

例として以下のシナリオを考えてみます。 （これはよく "カナディアンクロス（Canadian Cross）" とも呼ばれるものです。） コンパイラーが低速なマシン上にだけあるとします。 これをマシン A と呼び、コンパイラーは ccA とします。 これとは別に高速なマシン（マシン B）があって、ただしそこにはコンパイラーがありません。 そしてここから作り出すプログラムコードは、まったく別の低速マシン（マシン C）向けであるとします。 マシン C 向けにコンパイラーをビルドするためには、以下の 3 つの段階を経ることになります。

マシン C 上で必要となる他のプログラムは、高速なマシン B 上において cc2 を用いてコンパイルすることができます。 マシン B がマシン C 向けのプログラムを実行できなかったとすると、マシン C そのものが動作するようにならない限り、プログラムのビルドやテストは一切できないことになります。 たとえば ccC においてテストスイートを実行するには、以下の 4 つめの段階が必要になります。

上の例において cc1 と cc2 だけがクロスコンパイラーです。 つまりこのコンパイラーは、これを実行しているマシンとは別のマシンに対するコードを生成できるものです。 これに比べて ccA と ccC というコンパイラーは、実行しているマシンと同一マシン向けのコードしか生成できません。 そういうコンパイラーのこをネイティブ コンパイラーと呼びます。

LFS におけるクロスコンパイラーの実装方法

LFS ではクロスコンパイルに似せた作業を行うため、ホストのトリプレットを多少調整します。 LFS_TGT 変数において "vendor" 項目を変更します。 またクロスリンカーやクロスコンパイラーを生成する際には --with-sysroot オプションを利用します。 これはホスト内に必要となるファイルがどこにあるかを指示するものです。 第 6 章 においてビルドされる他のプログラムが、ビルドマシンのライブラリにリンクできないようにするためです。 以下の 2 段階は必須ですが、最後の 1 つはテスト用です。

上の表において "pc 上の" というのは、すでにそのディストリビューションにおいてインストールされているコマンドを実行することを意味します。 また "lfs 上の" とは、chroot 環境下にてコマンドを実行することを意味します。

話はまだまだあります。 C 言語というと単にコンパイラーがあるだけではなく、標準ライブラリも定義しています。 本書では glibc と呼ぶ GNU C ライブラリを用いています（別の選択肢として "musl" があります）。 このライブラリは lfs マシン向けにコンパイルされたものでなければなりません。 つまりクロスコンパイラー cc1 を使うということです。 しかしコンパイラーには内部ライブラリというものがあって、アセンブラー命令セットだけでは利用できない複雑なサブルーチンが含まれます。 その内部ライブラリは libgcc と呼ばれ、完全に機能させるには glibc ライブラリにリンクさせなければなりません。 さらに C++ (libstdc++) に対する標準ライブラリも、glibc にリンクさせる必要があります。 このようなニワトリと卵の問題を解決するには、まず libgcc に基づいた低機能版の cc1 をビルドします。 この cc1 にはスレッド処理や例外処理といった機能が含まれていません。 その後に、この低機能なコンパイラーを使って glibc をビルドします。 （glibc 自体は低機能ではありません。） そして libstdc++ をビルドします。 libstdc++ もやはり、libgcc の機能がいくつか欠如しています。

上の段落における結論は以下のようになります。 グレードの落ちた libgcc を使っている以上、cc1 からは完全な libstdc++ はビルドできないということです。 しかし第 2 段階においては、C/C++ ライブラリをビルドできる唯一のコンパイラーです。 第 2 段階でビルドしたコンパイラー cc-lfs を、そういったライブラリビルド用として即座には利用しない理由が 2 つあります。

そこで libstdc++ は、2 回めの gcc の一部として再ビルドしないといけません。 そこで GCC 2 回めのビルドにあたっては、cc1 を使って libgcc と libstdc++ を再ビルドするように指示します。 ただしこのとき、libstdc++ がリンクされるのは、デグレードした古い libgcc ではなく、新たに再ビルドされた libgcc です。 こうして libstdc++ は再ビルドによって完全な機能を備えることになります。

第 8 章 (つまり「3 回め」) において、LFS システムに必要なパッケージがすべてビルドされます。 それまでの章において、特定のパッケージがたとえ LFS システムにインストールされていても、再ビルドをし続けます。 そのようにしてパッケージを再ビルドする最大の理由は、そのパッケージを安定させるためです。 完全に仕上がった LFS システムに、どれかの LFS パッケージを再インストールしたとしたら、その際にインストールされる内容は、第 8 章 において初めてインストールされるものと、全く同一でなければなりません。 第 6 章 や 第 7 章 においてインストールする一時的なパッケージでは、この要件を満たしません。 なぜならそういったものに対しては、任意の依存パッケージを含めずにビルドしているからです。 また 第 6 章 において autoconf が行う機能チェックは、クロスコンパイルが原因で一部が適切に行われません。 そうなると一時パッケージには、オプション機能がコンパイルされなかったり、最適化が不十分なコードルーチンが用いられたりすることがあります。 さらにパッケージ再ビルドのもう一つの理由は、テストスイートを実行するためです。

その他の手順詳細

クロスコンパイラーは、他から切り離された $LFS/tools ディレクトリにインストールされます。 このクロスコンパイラーは、最終システムに含めるものではないからです。

binutils をまず初めにインストールします。 この後の gcc や glibc の configure スクリプトの実行ではアセンブラーやリンカーに対するさまざまな機能テストが行われるためで、そこではどの機能が利用可能または利用不能であるかが確認されます。 ただ重要なのは binutils を一番初めにビルドするという点だけではありません。 gcc や glibc の configure が正しく処理されなかったとすると、ツールチェーンがわずかながらも不完全な状態で生成されてしまいます。 この状態は、すべてのビルド作業を終えた最後になって、大きな不具合となって現れてくることになります。 テストスイートを実行することが欠かせません。 これを実行しておけば、この先に行う多くの作業に入る前に不備があることが分かるからです。

Binutils はアセンブラーとリンカーを二箇所にインストールします。 $LFS/tools/bin と $LFS/tools/$LFS_TGT/bin です。 これらは一方が他方のハードリンクとなっています。 リンカーの重要なところはライブラリを検索する順番です。 ld コマンドに --verbose オプションをつけて実行すれば詳しい情報が得られます。 例えば $LFS_TGT-ld --verbose | grep SEARCH を実行すると、検索するライブラリのパスとその検索順を示してくれます。 (この例は見て分かるように lfs ユーザーでログインしている場合のみ実行することができます。 この後にもう一度このページに戻ってきたときには、$LFS_TGT-ld を単に ld と置き換えてください。)

次にインストールするのは gcc です。 configure の実行時には以下のような出力が行われます。

checking what assembler to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/as
checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld

これを示すのには重要な意味があります。 gcc の configure スクリプトは、利用するツール類を探し出す際に PATH ディレクトリを参照していないということです。 しかし gcc の実際の処理にあたっては、その検索パスが必ず使われるわけでもありません。 gcc が利用する標準的なリンカーを確認するには gcc -print-prog-name=ld を実行します。 (上でも述べたように、後でこのページに戻ってきたときは $LFS_TGT- の部分を取り除いてください。)

gcc からさらに詳細な情報を知りたいときは、プログラムをコンパイルする際に -v オプションをつけて実行します。 たとえば $LFS_TGT-gcc -v example.c と (あるいは後にここに戻ってきたときは $LFS_TGT- 部分を除いて) 入力すると、プリプロセッサー、コンパイル、アセンブルの各処理工程が示されますが、さらに gcc がインクルードヘッダーを検索するパスとその読み込み順も示されます。

次に健全化された (sanitized) Linux API ヘッダーをインストールします。 これにより、標準 C ライブラリ (glibc) が Linux カーネルが提供する機能とのインターフェースを可能とします。

次のパッケージは glibc です。 glibc 構築の際に気にかけるべき重要なものは、コンパイラー、バイナリツール、カーネルヘッダーです。 コンパイラーやバイナリーツールについては、一般にはあまり問題にはなりません。 glibc は常に configure スクリプトにて指定される --host パラメーターに関連づけしたコンパイラーを用いるからです。 我々の作業においてそのコンパイラーとは $LFS_TGT-gcc であり、readelf ツールは $LFS_TGT-readelf になります。 カーネルヘッダーは多少複雑です。 したがって無理なことはせずに有効な configure オプションを選択することが必要です。 configure 実行の後は build ディレクトリにある config.make ファイルに重要な情報が示されているので確認してみてください。 これらの指定は Glibc パッケージの重要な面を示しています。 glibc がビルドされるメカニズムは自己完結したビルドが行われるものであり、ツールチェーンのデフォルト設定には基本的に依存しないことを示しています。

すでに述べたように、標準 C++ ライブラリはこの後にコンパイルします。 そして 第 6 章 では、自己依存性を持ったプログラムをビルドできるように、その依存性を無視するためにクロスコンパイル行っていきます。 そのようなパッケージのインストール手順においては DESTDIR 変数を使って、LFS ファイルシステム内にインストールするようにします。

第 6 章 の最後には、LFS のネイティブコンパイラーをインストールします。 はじめに DESTDIR ディレクトリを使って binutils 2 回めをビルドし、他のプログラムにおいても同じようにインストールを行います。 2 回めとなる gcc ビルドでは、不必要なライブラリは省略します。 gcc の configure スクリプトにはハードコーディングされている部分があるので、CC_FOR_TARGET はホストのターゲットが同じであれば cc になります。 しかしビルドシステムにおいては異なります。 そこで configure オプションには CC_FOR_TARGET=$LFS_TGT-gcc を明示的に指定するようにしています。

第 7 章での chroot による環境下では、各種プログラムのインストールを、ツールチェーンを適切に操作しながら実施していきます。 これ以降、コアとなるツールチェーンは自己完結していきます。 そしてシステムの全機能を動作させるための全パッケージの最終バージョンを、ビルドしテストしインストールします。