5.5. Glibc-2.41

5.5.1. Glibc のインストール

はじめに LSB コンプライアンスに合うように、シンボリックリンクを生成します。 さらに x86_64 向けとして、互換のシンボリックリンクを生成して、ダイナミックライブラリローダーが適切に動作するようにします。

case $(uname -m) in
    i?86)   ln -sfv ld-linux.so.2 $LFS/lib/ld-lsb.so.3
    ;;
    x86_64) ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64
            ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64/ld-lsb-x86-64.so.3
    ;;
esac

Glibc のプログラムの中で、FHS コンプライアンスに適合しない /var/db ディレクトリを用いているものがあり、そこに実行時データを保存しています。 以下のパッチを適用することで、実行時データの保存ディレクトリを FHS に合致するものとします。

patch -Np1 -i ../glibc-2.41-fhs-1.patch

Glibc のドキュメントでは、専用のビルドディレクトリを作成することが推奨されています。

mkdir -v build
cd       build

ldconfig と sln ユーティリティーを /usr/sbin にインストールするようにします。

echo "rootsbindir=/usr/sbin" > configparms

次に Glibc をコンパイルするための準備をします。

../configure                             \
      --prefix=/usr                      \
      --host=$LFS_TGT                    \
      --build=$(../scripts/config.guess) \
      --enable-kernel=5.4                \
      --disable-nscd                     \
      libc_cv_slibdir=/usr/lib

ビルド中には以下のようなメッセージが出力されるかもしれません。

msgfmt プログラムがない場合 (missing) や互換性がない場合 (incompatible) でも特に問題はありません。 msgfmt プログラムは Gettext パッケージが提供するもので、ホストシステムに含まれているかもしれません。

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

make

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

make DESTDIR=$LFS install

ldd スクリプト内にある実行可能なローダーへのパスがハードコーディングされているので、これを修正します。

sed '/RTLDLIST=/s@/usr@@g' -i $LFS/usr/bin/ldd

ここにクロスツールチェーンが用意できましたので、コンパイルとリンクが思うとおりに作動する確認をとることが必要になります。 以下の健全性チェックを実行してこれを確認します。

echo 'int main(){}' | $LFS_TGT-gcc -x c - -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'

エラーは出力しないはずであり、最後のコマンドからの出力は (ダイナミックリンカー名がプラットフォームごとに異なることを除けば) 以下のようになるはずです。

[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

このパスには /mnt/lfs (あるいは LFS に指定しているパス) は含まれていないはずです。 こうなるのも、そもそもパスが解釈されるのは、コンパイルしたプログラムが実行される際です。 そしてここでは chroot 環境に入っているため、カーネルが $LFS をルートディレクトリ (/) であると解釈しているからこそ、そのようになります。

ファイルが正しくできていることを確認します。

grep -E -o "$LFS/lib.*/S?crt[1in].*succeeded" dummy.log

最後のコマンドの出力は以下のようになるはずです。

/mnt/lfs/lib/../lib/Scrt1.o succeeded
/mnt/lfs/lib/../lib/crti.o succeeded
/mnt/lfs/lib/../lib/crtn.o succeeded

コンパイラーが正しいヘッダーファイルを読み取っているかどうかを検査します。

grep -B3 "^ $LFS/usr/include" dummy.log

上のコマンドは以下の出力を返します。

#include <...> search starts here:
 /mnt/lfs/tools/lib/gcc/x86_64-lfs-linux-gnu/14.2.0/include
 /mnt/lfs/tools/lib/gcc/x86_64-lfs-linux-gnu/14.2.0/include-fixed
 /mnt/lfs/usr/include

もう一度触れておきますが、プラットフォームの三つの組 (target triplet)の次にくるディレクトリ名は CPU アーキテクチャーにより異なる点に注意してください。

次に、新たなリンカーが正しいパスを検索して用いられているかどうかを検査します。

grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'

'-linux-gnu' を含んだパスは無視すれば、最後のコマンドの出力は以下となるはずです。

SEARCH_DIR("=/mnt/lfs/tools/x86_64-lfs-linux-gnu/lib64")
SEARCH_DIR("=/usr/local/lib64")
SEARCH_DIR("=/lib64")
SEARCH_DIR("=/usr/lib64")
SEARCH_DIR("=/mnt/lfs/tools/x86_64-lfs-linux-gnu/lib")
SEARCH_DIR("=/usr/local/lib")
SEARCH_DIR("=/lib")
SEARCH_DIR("=/usr/lib");

32ビットシステムではディレクトリが多少異なります。 ただしここで重要なことは、パス名の先頭がすべて等号記号 (=) で始まっている点です。 これはリンカーに対して設定した sysroot ディレクトリに置き換わります。

次に libc が正しく用いられていることを確認します。

grep "/lib.*/libc.so.6 " dummy.log

最後のコマンドの出力は以下のようになるはずです。

attempt to open /mnt/lfs/usr/lib/libc.so.6 succeeded

GCC が正しくダイナミックリンカーを用いているかを確認します。

grep found dummy.log

上のコマンドの出力は以下のようになるはずです。 (ダイナミックリンカーの名前はプラットフォームによって違っているかもしれません。)

found ld-linux-x86-64.so.2 at /mnt/lfs/usr/lib/ld-linux-x86-64.so.2

出力結果が上と異なっていたり、出力が全く得られなかったりした場合は、何かが根本的に間違っているということです。 どこに問題があるのか調査、再試行を行って解消してください。 問題を残したままこの先には進まないでください。

すべてが正しく動作したら、テストに用いたファイルを削除します。

rm -v a.out dummy.log