セルフコンパイル環境の整備：LFSで作って学ぶLinuxの仕組み（2）（1/2 ページ）

前回はLFSをインストールする受け皿となるパーティションを準備した。今回から、いよいよパッケージのコンパイルを始める。まずは自分（LFS）をコンパイルするためのプログラムをLFS用パーティションに用意する。（編集局）

[一志達也，＠IT]

インストールの流れ

　前回紹介したとおり、LFSのために用意したパーティション（/mnt/lfs）と入手したソースコードのパッケージを用いて、いよいよインストールを開始する。しかし、OS環境を一から構築するLFSが、単独で起動するまでの道のりは短くない。今回は、インストールの第一歩として、LFSをコンパイルするための環境作りを行う。

　前回、LFSをインストールするにはほかのLinuxディストリビューションが必要だと説明した。であれば、コンパイルするための環境としてそのディストリビューションを使うのではないかと思う人もいるだろう。それは当然なのだが、そうではないのだ。これから、LFSのインストールは2段階に分けて行う。

　1段階目が今回紹介する作業で、いわばインストール済みのLinuxと決別するための作業となる。インストールするのは、GCCやmakeといったコンパイルに必要なものと、tarやgzip、lsなどのファイル操作に必要なものが中心である。

2段階のインストールが必要な理由

　もちろん、GCCやtarといったプログラムはインストール済みのLinuxにも備わっている。では、なぜわざわざ別途インストールするのだろうか？

　私たちはいま、CD-ROMなどに用意されたインストーラを使わずに、まったく新規にOSをインストールしようとしている。そのためには、将来的に独立可能なディスクスペースと、そのディスクスペースへのファイル転送などを実行するOSが必要になる。これは、前回Linuxをインストールし、/mnt/lfsという独立したパーティションをマウントすることで実現された。

　次に必要なことは、用意したディスクスペースを独立させた後に、ファイル操作やプログラムのコンパイルが行える環境の準備である。今回行うのがこの作業なのだが、これによって用意される環境は、私たちの目指すOS環境とは違う。なぜなら、カーネルを持ち合わせていない。つまり、独立して起動することができない。起動済みのカーネルから、chrootを行ってファイル操作とコンパイルができるだけの環境なのである。

　chrootとは、あるディレクトリをルートディレクトリ（/）にしてしまうコマンドである。ここでは、/mnt/lfsを/に変更する。すると、それまで存在していたはずの/usr/localや/usr/sbinは見えなくなり、/mnt/lfs/usr/localが/usr/localになる。このとき、/bin（/mnt/lfs/bin）にlsコマンドがなければファイルの表示ができない。/usr/bin（/mnt/lfs/usr/bin）にGCCがなければソースのコンパイルが行えない。そうならないように、/mnt/lfs/binにlsを、/mnt/lfs/usr/binにGCCを用意してからchrootを行うのである。

ダイナミック・リンクとスタティック・リンク

　勘のいい方なら、ここで疑問が浮かぶだろう。なぜGCCなどと同時にカーネルやそのほかのコマンドもインストールしないのか？ 一度に済ませて、さっさと新しいOSを起動できないのか？ できそうに思えるかもしれないが、そういうわけにはいかない。その理由は、普段はあまり意識していない「ライブラリ」の存在にある。

　日ごろ何げなく使っているlsコマンドのファイルサイズは、筆者の手元の環境で45Kbytes程度である。しかし、このファイルだけではlsコマンドを使うことができない。「ls」というファイルに、lsの動作に必要なプログラムコードが全部入っているわけではないのである。これは、lsに限らず、大半のコマンドに同じことがいえる。

ダイナミック・リンク

　ファイルシステムへのアクセスや画面の制御など、多くのコマンドで共通利用するプログラムコードは、ライブラリと呼ばれる別なプログラムファイルに集められている。/usr/libなどに収められたファイル（拡張子がaやsoのもの）がそれに当たる。lsやtarなどのコマンドは、ライブラリに含まれる関数をコールすることで、自分のプログラムを簡略化しているのだ。さらに、ライブラリを利用することでディスクスペースとメモリスペースを節約できるメリットも大きい。このような仕組みを「ダイナミック・リンク」と呼ぶ。

　しかし、LFSをインストールしようとしているいま、これらのメリットが意味を成さないのである。lsにしてもtarにしても、そのコンパイル時にライブラリファイルを特定し、その場所をプログラムの内部に記録する（例えば/usr/lib/libc.a）。しかし、chrootした瞬間に、あるはずのライブラリファイルは存在しなくなる（chroot環境からは見えなくなる）のだ。

スタティック・リンク

　これからインストールしようとしているプログラムに、既存OS上のライブラリをリンクさせるわけにはいかないのである。そこで登場するのが「スタティック・リンク」と呼ばれる方法である。スタティック・リンクでは、本来ライブラリとして別ファイルに分離するはずの内容（コード）を、すべて取り込んでコンパイルする。この方法で作成したプログラムならば、ライブラリファイルが見えない状況になっても動作させることができる。

　ただし、この方法では各プログラムのファイルサイズが異常に大きくなってしまう。前述したように、筆者の環境ではライブラリを参照する（ダイナミック・リンクの）lsが約45Kbytesなのに対し、LFS用にスタティック・リンクでコンパイルしたlsは約2.7Mbytesもある。これが全部のプログラムに及んだのでは、ディスク容量がどれだけあっても足りない。

　そこで、LFSではスタティック・リンクで最小限必要なプログラムだけを用意し、chroot環境でも作業できる体制を確保する。そして、chrootしてからLFS環境にライブラリを構築し、ダイナミック・リンクであらためてプログラムをインストールするのである。

　「ライブラリもインストール済みの環境からコピーすれば済むのではないか？」と思うかもしれない。しかし、それでは、一から環境を構築するLFSの意味がないではないか。それにバージョンなどの問題もある。ここでは、そうしたやぼな考えは起こさないで、じっくりと事を進めていこう。

コラム　LFS Ver.4.0リリース

　10月に入って、LFSプロジェクトは新しいパッケージとなるバージョン4.0をリリースした。今回は検証作業が間に合わなかったので、3.3のままでコンパイルの詳細を伝えていくが、興味があれば4.0を試すのもよいだろう。

　すでに理解していると思うが、LFSのパッケージはコマンド別のソースコードの寄せ集めにすぎない。ただ、バージョンごとの互換性やコンパイル時のオプションに悩むことがないよう、動作検証の取れたバージョンを集めてマニュアル（LFS BOOK）を用意しているのである。新しいパッケージは、より新しいバージョンのコマンドを集めて、動作検証を行ってリリースしたものと考えればいいのだ。

　LFSで環境を構築する際は、パッケージに含まれるものより新しいバージョンを使いたければ使っても問題ない。逆に、必要のないコマンドや古いバージョンを使いたければそうしても構わない。マニュアルに従う必要もなく、好きなものを好きなようにインストールする。それこそがLFSの趣旨だからである。