本パッケージの詳細は 「Binutils の構成」を参照してください。
製作著作 © 1999-2022 Gerard Beekmans
Copyright © 1999-2022, Gerard Beekmans
All rights reserved.
本書は クリエイティブコモンズライセンス に従います。
本書のインストール手順のコマンドを抜き出したものは MIT ライセンス に従ってください。
Linux® は Linus Torvalds の登録商標です。
私が Linux について学び始め理解するようになったのは 1998 年頃からです。 Linux ディストリビューションのインストールを行ったのはその時が初めてです。 そして即座に Linux 全般の考え方や原理について興味を抱くようになりました。
何かの作業を完成させるには多くの方法があるものです。 同じことは Linux ディストリビューションについても言えます。 この数年の間に数多くのディストリビューションが登場しました。 あるものは今も存在し、あるものは他のものへと形を変え、そしてあるものは記憶の彼方へ追いやられたりもしました。 それぞれが利用者の求めに応じて、さまざまに異なる形でシステムを実現してきたわけです。 最終ゴールが同じものなのに、それを実現する方法はたくさんあるものです。 したがって私は一つのディストリビューションにとらわれることが不要だと思い始めました。 Linux が登場する以前であれば、オペレーティングシステムに何か問題があったとしても、他に選択肢はなくそのオペレーティングシステムで満足する以外にありませんでした。 それはそういうものであって、好むと好まざるは関係がなかったのです。 それが Linux になって "選ぶ" という考え方が出てきました。 何かが気に入らなかったら、いくらでも変えたら良いし、そうすることがむしろ当たり前となったのです。
数多くのディストリビューションを試してみましたが、これという1つに決定できるものがありませんでした。 個々のディストリビューションは優れたもので、それぞれを見てみれば正しいものです。 ただこれは正しいとか間違っているとかの問題ではなく、個人的な趣味の問題へと変化しています。 こうしたさまざまな状況を通じて明らかになってきたのは、私にとって完璧なシステムは1つもないということです。 そして私は自分自身の Linux を作り出して、自分の好みを満足させるものを目指しました。
本当に自分自身のシステムを作り出すため、私はすべてをソースコードからコンパイルすることを目指し、コンパイル済のバイナリパッケージは使わないことにしました。 この「完璧な」Linux システムは、他のシステムが持つ弱点を克服し、逆にすべての強力さを合わせ持つものです。 当初は気の遠くなる思いがしていましたが、そのアイデアは今も持ち続けています。
パッケージが相互に依存している状況やコンパイル時にエラーが発生するなどを順に整理していく中で、私はカスタムメイドの Linux を作り出したのです。 この Linux は今日ある他の Linux と比べても、十分な機能を有し十分に扱いやすいものとなっています。 これは私自身が作り出したものです。 いろいろなものを自分で組み立てていくのは楽しいものです。 さらに個々のソフトウェアまでも自分で作り出せれば、もっと楽しいものになるのでしょうが、それは次の目標とします。
私の求める目標や作業経験を他の Linux コミュニティの方々とも共有する中で、私の Linux への挑戦は絶えることなく続いていくことを実感しています。 このようなカスタムメイドの Linux システムを作り出せば、独自の仕様や要求を満たすことができるのはもちろんですが、さらにはプログラマーやシステム管理者の Linux 知識を引き伸ばす絶好の機会となります。 壮大なこの意欲こそが Linux From Scratch プロジェクト誕生の理由です。
Linux From Scratch ブックは関連プロジェクトの中心に位置するものです。 皆さんご自身のシステムを構築するために必要となる基礎的な手順を提供します。 本書が示すのは正常動作するシステム作りのための雛形となる手順ですので、皆さんが望んでいる形を作り出すために手順を変えていくことは自由です。 それこそ、本プロジェクトの重要な特徴でもあります。 そうしたとしても手順を踏み外すものではありません。 我々は皆さんが旅に挑戦することを応援します。
あなたの LFS システム作りが素晴らしいひとときとなりますように。 そしてあなた自身のシステムを持つ楽しみとなりますように。
--
Gerard Beekmans
gerard AT linuxfromscratch D0T org
本書を読む理由はさまざまにあると思いますが、よく挙がってくる質問として以下があります。 「既にある Linux をダウンロードしてインストールすれば良いのに、どうして苦労してまで手作業で Linux を構築しようとするのか。」
本プロジェクトを提供する最大の理由は Linux システムがどのようにして動作しているのか、これを学ぶためのお手伝いをすることです。 LFS システムを構築してみれば、さまざまなものが連携し依存しながら動作している様子を知ることができます。 そうした経験をした人であれば Linux システムを自分の望む形に作りかえる手法も身につけることができます。
LFS の重要な利点として、他の Linux システムに依存することなく、システムをより適切に制御できる点が挙げられます。 LFS システムではあなたが運転台に立って、システムのあらゆる側面への指示を下していきます。
さらに非常にコンパクトな Linux システムを作る方法も身につけられます。 通常の Linux ディストリビューションを用いる場合、多くのプログラムをインストールすることになりますが、たいていのプログラムは使わないものですし、その内容もよく分からないものです。 それらのプログラムはハードウェアリソースを無駄に占有することになります。 今日のハードドライブや CPU のことを考えたら、リソース消費は大したことはないと思うかもしれません。 しかし問題がなくなったとしても、サイズの制限だけは気にかける必要があることでしょう。 例えばブータブル CD、USB スティック、組み込みシステムなどのことを思い浮かべてください。 そういったものに対して LFS は有用なものとなるでしょう。
カスタマイズした Linux システムを構築するもう一つの利点として、セキュリティがあります。 ソースコードからコンパイルしてシステムを構築するということは、あらゆることを制御する権限を有することになり、セキュリティパッチは望みどおりに適用できます。 他の人がセキュリティホールを修正しバイナリパッケージを提供するのを待つ必要がなくなるということです。 他の人がパッチとバイナリパッケージを提供してくれたとしても、それが本当に正しく構築され、問題を解決してくれているかどうかは、調べてみなければ分からないわけですから。
Linux From Scratch の最終目標は、実用的で完全で、基盤となるシステムを構築することです。 Linux システムを一から作り出すつもりのない方は、本書から得られるものはないかもしれません。
LFS を構築する理由はさまざまですから、すべてを列記することはできません。 学習こそ、理由を突き詰める最大最良の手段です。 LFS 構築作業の経験を積むことによって、情報や知識を通じてもたらされる意義が十二分に理解できるはずです。
LFS が対象としている CPU アーキテクチャーは AMD/インテル x86 CPU (32ビット) と x86_64 CPU (64ビット) です。 Power PC や ARM については、本書の手順を多少修正することで動作することが確認されています。 これらの CPU を利用したシステムをビルドする場合は、この後に示す諸条件を満たす必要がありますが、まずはそのアーキテクチャーをターゲットとする、LFS システムそのものや Ubuntu、Red Hat/Fedora、SuSE などの Linux システムが必要です。 ホストが 64 ビット AMD/インテルによるシステムであったとしても 32 ビットシステムは問題なくインストールできます。
LFS の構築において 64 ビットシステムを用いることは 32 ビットシステムを用いた場合に比べて大きな効果はありません。 たとえば Core i7-4790 CPU 上において、4 コアを使って試しに LFS-9.1 をビルドしてみたところ、以下のような情報が得られました。
アーキテクチャー ビルド時間 ビルドサイズ
32 ビット 239.9 分 3.6 GB
64 ビット 233.2 分 4.4 GB
ご存知かと思いますが、同一ハードウェア上にて 64 ビットによりビルドを行っても、32 ビットのときのビルドに比べて 3% 早くなるだけで 22% は大きなものになります。 仮に LFS を使って LAMP サーバーやファイアーウォールを実現しようとする場合、32 ビット CPU を用いても十分機能するかもしれません。 一方 BLFS にあるパッケージの中には、ビルド時や実行時に 4GB 以上の RAM を必要としているものもあります。 このため LFS をデスクトップ環境に利用するなら、64 ビットシステムにおいてビルドすることをお勧めします。
LFS の手順に従って作り出す 64 ビットシステムは、「純粋な」64 ビットシステムと言えます。 つまりそのシステムは 64 ビット実行モジュールのみをサポートするということです。 「複数のライブラリ」によるシステムをビルドするのなら、多くのアプリケーションを二度ビルドしなければなりません。 一度は 32 ビット用であり、一度は 64 ビット用です。 本書ではこの点を直接サポートしていません。 この理由は、素直な Linux ベースシステムを構築するという LFS の教育的な目的とは合致しないからです。 LFS/BLFS 編集者の中に、マルチライブラリを行う LFS フォークを構築している方もいます。 これは https://www.linuxfromscratch.org/~thomas/multilib/index.html からアクセスすることができます。 ただしこれは応用的なトピックです。
LFS システムの構築作業は決して単純なものではありません。 ある程度の Unix システム管理の知識が必要です。 問題を解決したり、説明されているコマンドを正しく実行することが求められます。 ファイルやディレクトリのコピー、それらの表示確認、カレントディレクトリの変更、といったことは最低でも知っていなければなりません。 さらに Linux の各種ソフトウェアを使ったりインストールしたりする知識も必要です。
LFS ブックでは、最低でも そのようなスキルがあることを前提としていますので、数多くの LFS サポートフォーラムは、ひょっとすると役に立たないかもしれません。 フォーラムにおいて基本的な知識を尋ねたとしたら、誰も回答してくれないでしょう。 そうするよりも LFS に取り掛かる前に以下のような情報をよく読んでください。
LFS システムの構築作業に入る前に、以下を読むことをお勧めします。
ソフトウェア構築のハウツー (Software-Building-HOWTO) http://www.tldp.org/HOWTO/Software-Building-HOWTO.html
これは Linux 上において「一般的な」 Unix ソフトウェアを構築してインストールする方法を総合的に説明しています。 だいぶ前に書かれたものですが、ソフトウェアのビルドとインストールを行うために必要となる基本的な方法が程よくまとめられています。
ソースコードからのインストール入門ガイド (Beginner's Guide to Installing from Source) http://moi.vonos.net/linux/beginners-installing-from-source/
このガイドは、ソフトウェアをソースコードからビルドするために必要な基本的スキルや技術をほど良くまとめています。
LFS の構成は出来る限り Linux の各種標準に従うようにしています。 主な標準は以下のものです。
Linux Standard Base (LSB) Version 5.0 (2015)
LSB はさらに以下の4つの標準から構成されます。 コア (Core)、デスクトップ (Desktop)、ランタイム言語 (Runtime Languages)、画像処理 (Imaging) です。 また一般的な要求事項に加えて、アーキテクチャーに固有の要求事項もあります。 Gtk3 やグラフィックスという二項目に関しての試用も含んでいます。 LFS では前節にて示したように、各アーキテクチャーに適合することを目指します。
LSB の要求に対しては異論のある方も多いでしょう。 LSB を定義するのは、私有ソフトウェア (proprietary software) をインストールした場合に、要求事項を満たしたシステム上にて問題なく動作することを目指すためです。 LFS はソースコードから構築するシステムですから、どのパッケージを利用するかをユーザー自身が完全に制御できます。 また LSB にて要求されているパッケージであっても、インストールしない選択をとることもできます。
LFS の構築にあたっては LSB に適合していることを確認するテスト (certifications tests) をクリアするように構築することも可能です。 ただし LFS の範囲外にあるパッケージ類を追加しなければ実現できません。 そのような追加パッケージ類については、おおむね BLFS にて導入手順を説明しています。
LSB コア: |
Bash, Bc, Binutils, Coreutils, Diffutils, File, Findutils, Gawk, Grep, Gzip, M4, Man-DB, Ncurses, Procps, Psmisc, Sed, Shadow, Tar, Util-linux, Zlib |
LSB デスクトップ: |
なし |
LSB ランタイム言語: |
Perl, Python |
LSB 画像処理: |
なし |
LSB Gtk3、LSB グラフィックス (試用): |
なし |
LSB コア: |
At, Batch (At の一部), Cpio, Ed, Fcrontab, LSB-Tools, NSPR, NSS, PAM, Pax, Sendmail (または Postfix または Exim), time |
LSB デスクトップ: |
Alsa, ATK, Cairo, Desktop-file-utils, Freetype, Fontconfig, Gdk-pixbuf, Glib2, GTK+2, Icon-naming-utils, Libjpeg-turbo, Libpng, Libtiff, Libxml2, MesaLib, Pango, Qt4, Xdg-utils, Xorg |
LSB ランタイム言語: |
Libxml2, Libxslt |
LSB 画像処理: |
CUPS, Cups-filters, Ghostscript, SANE |
LSB Gtk3、LSB グラフィックス (試用): |
GTK+3 |
既に説明しているように LFS が目指すのは、完成した形での実用可能な基盤システムを構築することです。 LFS に含まれるパッケージ群は、パッケージの個々を構築していくために必要となるものばかりです。 そこからは最小限の基盤となるシステムを作り出します。 そしてユーザーの望みに応じて、より完璧なシステムへと拡張していくものとなります。 LFS は極小システムを意味するわけではありません。 厳密には必要のないパッケージであっても、重要なものとして含んでいるものもあります。 以下に示す一覧は、本書内の各パッケージの採用根拠について説明するものです。
Acl
このパッケージはアクセス制御リスト (Access Control Lists) を管理するツールを提供します。 これはファイルやディレクトリに対して、きめ細かく様々なアクセス権限を定義するために利用されます。
Attr
このパッケージはファイルシステムオブジェクト上の拡張属性を管理するプログラムを提供します。
Autoconf
このパッケージは、以下に示すようなシェルスクリプトを生成するプログラムを提供します。 つまり開発者が意図しているテンプレートに基づいて、ソースコードを自動的に設定する (configure する) ためのシェルスクリプトです。 特定のパッケージのビルド方法に変更があった場合は、パッケージ再構築を行うことになるため、その場合に本パッケージが必要となります。
Automake
このパッケージは、テンプレートとなるファイルから Makefile を生成するためのプログラムを提供します。 特定のパッケージのビルド方法に変更があった場合は、パッケージ再構築を行うことになるため、その場合に本パッケージが必要となります。
Bash
このパッケージは、システムとのインターフェースを実現する Bourne シェルを提供し、LSB コア要件を満たします。 他のシェルを選ばずにこれを選ぶのは、一般的に多用されていることと、基本的なシェル関数においての拡張性が高いからです。
Bc
このパッケージは、任意精度 (arbitrary precision) の演算処理言語を提供します。 Linux カーネルの構築に必要となります。
Binutils
このパッケージは、リンカー、アセンブラーのような、オブジェクトファイルを取り扱うプログラムを提供します。 各プログラムは LFS における他のパッケージをコンパイルするために必要となり、さらに LFS にて示される以外のパッケージでも必要となります。
Bison
このパッケージは yacc (Yet Another Compiler Compiler) の GNU バージョンを提供します。 LFS において利用するプログラムの中に、これを必要とするものがあります。
Bzip2
このパッケージは、ファイルの圧縮、伸張 (解凍) を行うプログラムを提供します。 これは LFS パッケージの多くを伸張 (解凍) するために必要です。
Check
このパッケージは、他のプログラムに対するテストハーネス (test harness) を提供します。
Coreutils
このパッケージは、ファイルやディレクトリを参照あるいは操作するための基本的なプログラムを数多く提供します。 各プログラムはコマンドラインからの実行によりファイル制御を行うために必要です。 また LFS におけるパッケージのインストールに必要となります。
D-Bus
このパッケージはメッセージバスシステムを実装しています。 これはアプリケーション間での通信手段を容易にするものです。
DejaGNU
このパッケージは、他のプログラムをテストするフレームワークを提供します。
Diffutils
このパッケージは、ファイルやディレクトリ間の差異を表示するプログラムを提供します。 各プログラムはパッチを生成するために利用されます。 したがってパッケージのビルド時に利用されることが多々あります。
E2fsprogs
このパッケージは ext2, ext3, ext4 の各ファイルシステムを取り扱うユーティリティを提供します。 各ファイルシステムは Linux がサポートする一般的なものであり、十分なテストが実施されているものです。
Expat
このパッケージは比較的小規模の XML 解析ライブラリを提供します。 XML-Parser Perl モジュールがこれを必要とします。
Expect
このパッケージは、スクリプトで作られた対話型プログラムを通じて、他のプログラムとのやりとりを行うプログラムを提供します。 通常は他のパッケージをテストするために利用します。
File
このパッケージは、指定されたファイルの種類を判別するユーティリティプログラムを提供します。 他のパッケージのビルドスクリプト内にてこれを必要とするものもあります。
Findutils
このパッケージは、ファイルシステム上のファイルを検索するプログラムを提供します。 これは他のパッケージにて、ビルド時のスクリプトにおいて利用されています。
Flex
このパッケージは、テキスト内の特定パターンの認識プログラムを生成するユーティリティを提供します。 これは lex (字句解析; lexical analyzer) プログラムの GNU 版です。 LFS 内の他のパッケージの中にこれを必要としているものがあります。
Gawk
このパッケージはテキストファイルを操作するプログラムを提供します。 プログラムは GNU 版の awk (Aho-Weinberg-Kernighan) です。 これは他のパッケージにて、ビルド時のスクリプトにおいて利用されています。
GCC
これは GNU コンパイラーコレクションパッケージです。 C コンパイラーと C++ コンパイラーを含みます。また LFS ではビルドしないコンパイラーも含まれています。
GDBM
このパッケージは GNU データベースマネージャーライブラリを提供します。 LFS が扱う Man-DB パッケージがこれを利用しています。
Gettext
このパッケージは、各種パッケージが国際化を行うために利用するユーティリティやライブラリを提供します。
Glibc
このパッケージは C ライブラリです。Linux 上のプログラムはこれがなければ動作させることができません。
GMP
このパッケージは数値演算ライブラリを提供するもので、任意精度演算 (arbitrary precision arithmetic) についての有用な関数を含みます。 これは GCC をビルドするために必要です。
Gperf
このパッケージは、キーセットから完全なハッシュ関数を生成するプログラムを提供します。 Eudev がこれを必要としています。
Grep
このパッケージはファイル内を検索するプログラムを提供します。 これは他のパッケージにて、ビルド時のスクリプトにおいて利用されています。
Groff
このパッケージは、テキストを処理し整形するプログラムをいくつか提供します。 重要なものプログラムとして man ページを生成するものを含みます。
GRUB
これは Grand Unified Boot Loader です。 ブートローダーとして利用可能なものの中でも、これが最も柔軟性に富むものです。
Gzip
このパッケージは、ファイルの圧縮と伸張 (解凍) を行うプログラムを提供します。 LFS において、パッケージを伸張 (解凍) するために必要です。
Iana-etc
このパッケージは、ネットワークサービスやプロトコルに関するデータを提供します。 ネットワーク機能を適切に有効なものとするために、これが必要です。
Inetutils
このパッケージは、ネットワーク管理を行う基本的なプログラム類を提供します。
Intltool
本パッケージはソースファイルから翻訳対象となる文字列を抽出するツールを提供します。
IProute2
このパッケージは、IPv4、IPv6 による基本的な、あるいは拡張したネットワーク制御を行うプログラムを提供します。 IPv6 への対応があることから、よく使われてきたネットワークツールパッケージ (net-tools) に変わって採用されました。
Jinja2
このパッケージは、テキストテンプレート処理を行う Python モジュールです。 Systemd のビルドに必要となります。
Kbd
このパッケージは、米国以外のキーボードに対してのキーテーブルファイルやキーボードユーティリティを提供します。 また端末上のフォントも提供します。
Kmod
このパッケージは Linux カーネルモジュールを管理するために必要なプログラムを提供します。
Less
このパッケージはテキストファイルを表示する機能を提供するものであり、表示中にスクロールを可能とします。 また Man-DB において man ページを表示する際にも利用されます。
Libcap
このパッケージは Linux カーネルにて利用される POSIX 1003.1e 機能へのユーザー空間からのインターフェースを実装します。
Libelf
elfutils プロジェクトでは、ELF ファイルや DWARF データに対するライブラリやツールを提供しています。 他のパッケージに対して各種ユーティリティーは有用なものですが、ライブラリは Linux カーネルのビルドに必要であり、デフォルトの(最も効果的な)カーネル設定にて利用されます。
Libffi
このパッケージは、さまざまな呼出規約(calling conventions)に対しての、移植性に優れた高レベルプログラミングインターフェースを提供します。 プログラムをコンパイルするその時点においては、関数に対してどのような引数が与えられるかが分からない場合があります。 例えばインタープリターの場合、特定の関数を呼び出す際の引数の数や型は、実行時に指定されます。 libffi はそういうプログラムであっても、インタープリタープログラムからコンパイルコードへのブリッジを提供します。
Libpipeline
Libpipeline パッケージは、サブプロセスのパイプラインを柔軟にかつ容易に操作するライブラリを提供します。 これは Man-DB パッケージが必要としています。
Libtool
このパッケージは GNU の汎用的なライブラリに対してのサポートスクリプトを提供します。 これは、複雑な共有ライブラリの取り扱いを単純なものとし、移植性に優れた一貫した方法を提供します。 LFS パッケージのテストスイートにおいて必要となります。
Linux Kernel
このパッケージは "オペレーティングシステム" であり GNU/Linux 環境における Linux です。
M4
このパッケージは汎用的なテキストマクロプロセッサーであり、他のプログラムを構築するツールとして利用することができます。
Make
このパッケージは、パッケージ構築を指示するプログラムを提供します。 LFS におけるパッケージでは、ほぼすべてにおいて必要となります。
MarkupSafe
このパッケージは、HTML/XHTML/XML 内の文字列を安全に処理するための Python モジュールです。 Jinja2 がこのパッケージを必要としています。
Man-DB
このパッケージは man ページを検索し表示するプログラムを提供します。 man パッケージではなく本パッケージを採用しているのは、その方が国際化機能が優れているためです。 このパッケージは man プログラムを提供しています。
Man-pages
このパッケージは Linux の基本的な man ページを提供します。
Meson
このパッケージは、ソフトウェアを自動的にビルドするソフトウエアツールを提供します。 Meson が目指すのは、ソフトウェア開発者がビルドシステムの設定にかける時間を、できるだけ減らすことにあります。 これは Systemd のビルドに必要であり、また BLFS における多くのパッケージにも必要です。
MPC
このパッケージは複素数演算のための関数を提供します。 GCC パッケージがこれを必要としています。
MPFR
このパッケージは倍精度演算 (multiple precision) の関数を提供します。 GCC パッケージがこれを必要としています。
Ninja
このパッケージは、処理速度を重視した軽量なビルドシステムを提供します。 高レベルなビルドシステムが生成したファイルを入力として、ビルド実行をできるだけ高速に行うように設計されています。 このパッケージは Meson が必要としています。
Ncurses
このパッケージは、端末に依存せず文字キャラクターを取り扱うライブラリを提供します。 メニュー表示時のカーソル制御を実現する際に利用されます。 LFS の他のパッケージでは、たいていはこれを必要としています。
Openssl
このパッケージは暗号化に関する管理ツールやライブラリを提供します。 Linux カーネルや他のパッケージに対して、暗号化機能を提供するものとして有用です。
Patch
このパッケージは、パッチ ファイルの適用により、特定のファイルを修正したり新規生成したりするためのプログラムを提供します。 パッチファイルは diff プログラムにより生成されます。 LFS パッケージの中には、構築時にこれを必要とするものがあります。
Perl
このパッケージは、ランタイムに利用されるインタープリター言語 PERL を提供します。 LFS の他のパッケージでは、インストール時やテストスイートの実行時にこれを必要とするものがあります。
Pkg-config
このパッケージは、既にインストールされたライブラリやパッケージのメタデータを取得するプログラムを提供します。
Procps-NG
このパッケージは、プロセスの監視を行うプログラムを提供します。 システム管理にはこのパッケージが必要となります。 また LFS ブートスクリプトではこれを利用しています。
Psmisc
このパッケージは、実行中のプロセスに関する情報を表示するプログラムを提供します。 システム管理にはこのパッケージが必要となります。
Python 3
このパッケージは、ソースコードの可読性の向上を意図して開発されたインタープリター言語を提供します。
Readline
このパッケージは、コマンドライン上での入力編集や履歴管理を行うライブラリを提供します。 これは Bash が利用しています。
Sed
このパッケージは、テキストの編集を、テキストエディターを用いることなく可能とします。 LFS パッケージにおける configure スクリプトは、たいていこれを必要としています。
Shadow
このパッケージは、セキュアな手法によりパスワード制御を行うプログラムを提供します。
Systemd
このパッケージは Sysvinit の代替として、init プログラムなど数種のプログラムにより、システム起動やシステム制御を実現します。 商用ディストリビューションにおいてもよく利用されています。
Tar
このパッケージは、アーカイブや圧縮機能を提供するもので LFS が扱うすべてのパッケージにて利用されています。
Tcl
このパッケージはツールコマンド言語 (Tool Command Language) を提供します。 LFS が扱うパッケージにてテストスイートの実行に必要となります。
Texinfo
このパッケージは Info ページに関しての入出力や変換を行うプログラムを提供します。 LFS が扱うパッケージのインストール時には、たいてい利用されます。
Util-linux
このパッケージは数多くのユーティリティプログラムを提供します。 その中には、ファイルシステムやコンソール、パーティション、メッセージなどを取り扱うユーティリティがあります。
Wheel
このパッケージは Python wheel パッケージング標準に基づいた標準実装の Python モジュールを提供します。
Vim
このパッケージはテキストエディターを提供します。 これを採用しているのは、従来の vi エディタとの互換性があり、しかも数々の有用な機能を提供するものだからです。 テキストエディターは個人により好みはさまざまですから、もし別のエディターを利用したいなら、そちらを用いても構いません。
XML::Parser
このパッケージは Expat とのインターフェースを実現する Perl モジュールです。
XZ Utils
このパッケージはファイルの圧縮、伸張 (解凍) を行うプログラムを提供します。 一般的に用いられるものの中では高い圧縮率を実現するものであり、特に XZ フォーマットや LZMA フォーマットの伸張 (解凍) に利用されます。
Zlib
このパッケージは、圧縮や解凍の機能を提供するもので、他のプログラムがこれを利用しています。
Zstd
このパッケージは、一定のプログラムが利用している圧縮、伸張(解凍)ルーチンを提供します。 高圧縮率に加えて、圧縮、処理速度間のトレードオフを広範囲に提供します。
本書では、特定の表記を用いて分かりやすく説明を行っていきます。 ここでは Linux From Scratch ブックを通じて利用する表記例を示します。
./configure --prefix=/usr
この表記は特に説明がない限りは、そのまま入力するテキストを示しています。 またコマンドの説明を行うために用いる場合もあります。
場合によっては、1行で表現される内容を複数行に分けているものがあります。 その場合は各行の終わりにバックスラッシュ (あるいは円記号) を表記しています。
CC="gcc -B/usr/bin/" ../binutils-2.18/configure \ --prefix=/tools --disable-nls --disable-werror
バックスラッシュ (または円記号) のすぐ後ろには改行文字がきます。 そこに余計な空白文字やタブ文字があると、おかしな結果となるかもしれないため注意してください。
install-info: unknown option '--dir-file=/mnt/lfs/usr/info/dir'
上の表記は固定幅フォントで示されており、たいていはコマンド入力の結果として出力される端末メッセージを示しています。 あるいは
/etc/ld.so.conf
といったファイル名を示すのに利用する場合もあります。
ブラウザーの設定において、固定幅テキストに対しては適切なモノスペースフォントを用いるようにしてください。
これを設定していれば、Il1
や O0
のグリフを適切に識別できます。
Emphasis
上の表記はさまざまな意図で用いています。 特に重要な説明内容やポイントを表します。
https://www.linuxfromscratch.org/
この表記は LFS コミュニティ内や外部サイトへのハイパーリンクを示します。 そこには「ハウツー」やダウンロードサイトなどが含まれます。
cat > $LFS/etc/group << "EOF"
root:x:0:
bin:x:1:
......
EOF
上の表記は設定ファイル類を生成する際に示します。 1行目のコマンドは $LFS/etc/group
というファイルを生成することを指示しています。
そのファイルへは2行目以降 EOF が記述されるまでのテキストが出力されます。 したがってこの表記は通常そのままタイプ入力します。
<REPLACED TEXT>
上の表記は入力するテキストを仮に表現したものです。 これをそのまま入力するものではないため、コピー、ペースト操作で貼り付けないでください。
[OPTIONAL TEXT]
上の表記は入力しなくてもよいオプションを示しています。
passwd(5)
上の表記はマニュアルページ (man
ページ) を参照するものです。 カッコ内の数字は man の内部で定められている特定のセクションを表しています。
例えば passwd
コマンドには2つのマニュアルページがあります。 LFS のインストールに従った場合、2つのマニュアルページは
/usr/share/man/man1/passwd.1
と
/usr/share/man/man5/passwd.5
に配置されます。 passwd(5)
という表記は
/usr/share/man/man5/passwd.5
を参照することを意味します。 man
passwd という入力に対しては「passwd」という語に合致する最初のマニュアルページが表示されるものであり
/usr/share/man/man1/passwd.1
が表示されることになります。 特定のマニュアルページを見たい場合は man 5 passwd といった入力を行う必要があります。
マニュアルページが複数あるケースはまれですので、普通は man
<プログラム名> と入力するだけで十分です。
本書は以下の部から構成されます。
第 I 部では LFS 構築作業を進めるための重要事項について説明します。 また本書のさまざまな情報についても説明します。
第 II 部では、パーティションの生成、パッケージのダウンロード、一時的なツールのコンパイルといった、システム構築の準備作業について説明します。
第 III 部では、最終的な LFS システム構築のために必要となるツールのビルド説明を行います。
第 IV 部では LFS システムの構築作業を順に説明していきます。 そこでは全パッケージのコンパイルとインストール、ブートスクリプトの設定、カーネルのインストールを行います。 出来上がる Linux システムをベースとして、他のソフトウェアを必要に応じて導入し、このシステムを拡張していくことができます。 本書の終わりには、インストール対象のプログラム、ライブラリ、あるいは重要なファイル類についてのさくいんも示します。
第 V 部では、本書における略語や用語、謝辞、パッケージの依存関係、LFS ブートスクリプトの一覧、本書配布のライセンス、パッケージ、プログラム、ライブラリ、スクリプトのさくいんを示します。
LFS システムを構築するためのソフトウェアは日々拡張され更新されています。 LFS ブックがリリースされた後に、セキュリティフィックスやバグフィックスが公開されているかもしれません。 本版にて説明するパッケージや作業手順に対して、セキュリティフィックスやバグフィックス等が必要かどうか、ビルド作業を行う前に https://www.linuxfromscratch.org/lfs/errata/11.2-systemd/ を確認してください。 そして LFS ビルド作業を進めながら、対応する節においての変更を確認し適用してください。
上に加えて Linux From Scratch 編集者は、本ブックのリリース後に発見されたセキュリティぜい弱性のリストを管理しています。 ビルド作業に入る前には https://www.linuxfromscratch.org/lfs/advisories/ にアクセスして、重大なセキュリティぜい弱性がないかどうかを事前に確認してください。 LFS のビルド作業を進めていく上では、必ずセキュリティアドバイスを確認し、セキュリティぜい弱性を解消する修正手順があれば、それに従ってください。
本節はオリジナルの LFS ブックにはないものです。 日本語訳に関する情報を示すために設けました。
本書は LFS ブック 11.2-systemd の日本語版 20220901 です。 オリジナルの LFS ブックと同様に DocBook を用いて構築しています。
日本語版 LFS ブックは OSDN.jp 内に開発の場を設け http://lfsbookja.osdn.jp/ にて「LFSブック日本語版」のプロジェクト名で提供するものです。
HTML ファイル類や日本語化のために構築しているソース類について、あるいはそれらの取り扱い (ライセンス) については上記サイトを参照してください。
日本語版 LFS ブックの生成は、以下のようにして行っています。
そもそも LFS ブックのソースは、LFS のサイト https://www.linuxfromscratch.org/ において、Stable 版として公開されていると同時に Subversion により、日々開発更新されているソース (XMLソース) が公開されています。 日本語版はその XML ソースに基づいて作成しています。
XML ソースは
DocBook XML DTD
の書式に従ったファイル形式です。
日本語版では、ソースに記述された原文を日本語訳文に変えて、同様の処理により生成しています。 ソース内に含まれる
INSTALL
ファイルには、処理に必要となるツール類の詳細が示されています。 それらのツール類はすべて BLFS
にてインストールする対象となっていますので、興味のある方は参照してください。
日本語訳にあたっては、原文にて「地の文」として表現されている文章を日本語化しています。 逆に各手順におけるコマンド説明 (四角の枠囲いで示されている箇所) は、日本語化の対象とはしていません。 コマンド類や設定記述が英単語で行われるわけですから、これは当たり前のことです。 ただ厳密に言えば、その四角の枠囲いの中でシェルのコメント書きが含まれる場合があり、これは日本語化せずそのまま表記しています。
日本語版 LFS ブックを参照頂く際には、以下の点に注意してください。
本ページの冒頭にあるように、原文にはない記述は「日本語訳情報」として枠囲い文章で示すことにします。
訳者は Linux に関する知識を隅から隅まで熟知しているわけではありません。 したがってパッケージのことや Linux の仕組みに関して説明されている原文の、真の意味が捉えられず、原文だけを頼りに訳出している箇所もあります。 もし誤訳、不十分な訳出、意味不明な箇所に気づかれた場合は、是非ご指摘、ご教示をお願いしたいと思います。
日本語訳にて表記しているカタカナ用語について触れておきます。 特に語末に長音符号がつく (あるいはつかない) 用語です。 このことに関しては訳者なりに捉えているところがあるのですが、詳述は省略します。 例えば「ユーザー (user)」という用語は語末に長音符号をつけるべきと考えます。 一方「コンピュータ (computer)」という用語は、情報関連その他の分野では長音符号をつけない慣用があるものの、昨今これをつけるような流れもあり情勢が変わりつつあります。 このように用語表記については、大いに "ゆれ" があるため、訳者なりに取り決めて表記することにしています。 なじみの表記とは若干異なるものが現れるかもしれませんが、ご了承いただきたいと思います。
LFS システムは、既にインストールされている Linux ディストリビューション (Debian、OpenMandriva、Fedora、openSUSE など) を利用して構築していきます。 この既存の Linux システム(ホスト)は、LFS 構築のためにさまざまなプログラム類を利用する基盤となります。 プログラム類とはコンパイラー、リンカー、シェルなどです。 したがってそのディストリビューションのインストール時には「開発 (development)」オプションを選択し、それらのプログラム類が利用できるようにしておく必要があります。
コンピューター内にインストールされているディストリビューションを利用するのではなく、他に提供されている LiveCD を利用することもできます。
第 2 章では、新しく構築する Linux のためのパーティションとファイルシステムの生成方法について説明します。 そのパーティション上にて LFS システムをコンパイルしインストールします。 第 3 章では LFS 構築に必要となるパッケージとパッチについて説明します。 これらをダウンロードして新たなファイルシステム内に保存します。 第 4 章は作業環境の準備について述べています。 この章では重要な説明を行っていますので、第 5 章以降に進む前に是非注意して読んでください。
第 5 章では初期のツールチェーン(binutils、gcc、glibc)を、クロスコンパイルによりインストールします。 これによりこの新たなツールをホストシステムから切り離します。
第 6 章では、上で作ったクロスツールチェーンを利用して、基本的ユーティリティのクロスコンパイル方法を示します。
第 7 章では "chroot" 環境に入ります。 そして今作り上げたビルドツールを使って、最終的なシステムをビルドしテストするために必要となる残りのツールをビルドします。
ホストシステムのツール類から新しいシステムを切り離していくこの手順は、やり過ぎのように見えるかもしれません。 ツールチェーンの技術的情報にて詳細に説明しているので参照してください。
第 8 章において完全な LFS システムが出来上がります。 chroot を使うもう一つのメリットは、LFS 構築作業にあたって引き続きホストシステムを利用できることです。 パッケージをコンパイルしている最中には、通常どおり別の作業を行うことができます。
インストールの仕上げとして第 9 章にてベースシステムの設定を行い、第 10 章にてカーネルとブートローダーを設定します。 第 11 章では LFS システム構築経験を踏まえて、その先に進むための情報を示します。 本書に示す作業をすべて実施すれば、新たな LFS システムを起動することが出来ます。
上はごく簡単な説明にすぎません。 各作業の詳細はこれ以降の章やパッケージの説明を参照してください。 内容が難しいと思っていても、それは徐々に理解していけるはずです。 読者の皆さんには、是非 LFS アドベンチャーに挑んで頂きたいと思います。
以下に示すのは前版から変更されているパッケージです。
アップグレード:
Bc 6.0.1
Binutils-2.39
Coreutils-9.1
D-Bus-1.14.0
E2fsprogs-1.46.5
Expat-2.4.8
File-5.42
GCC-12.2.0
Glibc-2.36
Gzip-1.12
IANA-Etc-20220812
Inetutils-2.3
IPRoute2-5.19.0
Jinja2-3.1.2
Kbd-2.5.1
Kmod-30
Libcap-2.65
Libelf-0.187 (from elfutils)
Libpipeline-1.5.6
Libtool-2.4.7
Linux-5.19.2
Man-DB-2.10.2
MarkupSafe-2.1.1
Meson-0.63.1
Ninja-1.11.0
Openssl-3.0.5
Perl-5.36.0
Procps-ng-4.0.0
Psmisc-23.5
Python-3.10.6
Shadow-4.12.2
Systemd-251
Tzdata-2022c
Util-Linux-2.38.1
Vim-9.0.0228
XZ-Utils-5.2.6
Zlib-1.2.12
追加:
Wheel-0.37.1
zstd-1.5.2-upstream_fixes-1.patch
削除:
perl-5.34.0-upstream_fixes-1.patch
systemd-250-kernel_5.17_fixes-1.patch
systemd-250-upstream_fixes-1.patch
本書は Linux From Scratch ブック、バージョン 11.2-systemd、2022/09/01 公開です。 本書が 6ヶ月以上更新されていなければ、より新しい版が公開されているはずです。以下のミラーサイトを確認してください。 https://www.linuxfromscratch.org/mirrors.html
以下は前版からの変更点を示したものです。
変更履歴
2022-09-01
[bdubbs] - LFS-11.2 リリース
2022-08-20
[bdubbs] - vim-9.0.0228 へのアップデート。 #4500 にて言及。
[bdubbs] - iana-etc-20220812 へのアップデート。 #5006 にて言及。
[bdubbs] - gcc-12.2.0 へのアップデート。 #5098 を Fix に。
[bdubbs] - linux-5.19.2 (セキュリティフィックス) へのアップデート。 #5097 を Fix に。
[bdubbs] - tzdata-2022c へのアップデート。 #5096 を Fix に。
[bdubbs] - shadow-4.12.2 (セキュリティフィックス) へのアップデート。 #5095 を Fix に。
[bdubbs] - meson-0.63.1 へのアップデート。 #5094 を Fix に。
[bdubbs] - xz-5.2.6 へのアップデート。 #5093 を Fix に。
2022-08-18
[xry111] - 5 章 6 章において libtool アーカイブファイル (.la) を削除。 クロスコンパイルにとっては邪魔になるため。
2022-08-11
2022-08-06
2022-07-24
2022-07-15
2022-07-01
2022-06-29
[pierre] - ncurses における C++ バインディングに関して、スタティックなバインディングを生成してから削除するのではなく、共有バインディングを生成することに。
2022-06-14
2022-05-29
2022-05-29
2022-05-16
2022-05-01
[bdubbs] - openssl-3.0.3 へのアップデート。 #5057 を Fix に。
2022-05-01
[bdubbs] - nobody/nogroup の uid/gid を 65534 に変更。
[bdubbs] - meson-0.62.1 へのアップデート。 #5052 を Fix に。
[bdubbs] - libpipeline-1.5.6 へのアップデート。 #5053 を Fix に。
[bdubbs] - elfutils-0.187 へのアップデート。 #5054 を Fix に。
[bdubbs] - Jinja2-3.1.2 へのアップデート。 #5055 を Fix に。
[bdubbs] - vim-8.2.4814 へのアップデート。 #4500 において言及。
[bdubbs] - linux-5.17.5 へのアップデート。 #5050 を Fix に。
[bdubbs] - gcc-11.3.0 へのアップデート。 #5051 を Fix に。
[bdubbs] - coreutils-9.1 へのアップデート。 #5048 を Fix に。
[bdubbs] - bc-5.2.4 へのアップデート。 #5049 を Fix に。
2022-04-15
[bdubbs] - wheel-0.37.1 (Python モジュール) 追加。
2022-04-15
2022-03-31
[bdubbs] - zlib-1.2.12 へのアップデート (セキュリティアップデート)。 #5040 を Fix に。
[bdubbs] - expat-2.4.8 へのアップデート。 #5039 を Fix に。
[bdubbs] - Jinja2-3.1.1 へのアップデート。 #5038 を Fix に。
[bdubbs] - Python-3.10.4 へのアップデート。 #5037 を Fix に。
[bdubbs] - procps-ng-4.0.0 へのアップデート。 #5036 を Fix に。
[bdubbs] - iproute2-5.17.0 へのアップデート。 #5035 を Fix に。
[bdubbs] - meson-0.62.0 へのアップデート。 #5034 を Fix に。
[bdubbs] - linux-5.17.1 へのアップデート (セキュリティアップデート)。 #5033 を Fix に。
[bdubbs] - util-linux-2.38 へのアップデート。 #4997 を Fix に。
2022-03-25
[pierre] - bootscripts を 20220324 にアップデート。 #5027 を Fix に。
2022-03-20
2022-03-16
[xry111] - MarkupSafe-2.1.1 へのアップデート。 #5025 を Fix に。
2022-03-15
[bdubbs] - openssl-3.0.2 へのアップデート。 #5024 を Fix に。
[bdubbs] - meson-0.61.3 へのアップデート。 #5023 を Fix に。
[xry111] - expat-2.4.7 へのアップデート。 #5019 を Fix に。
[xry111] - bc-5.2.3 へのアップデート。 #5020 を Fix に。
[xry111] - linux-5.16.14 (セキュリティフィックス) へのアップデート。 #5021 を Fix に。
[xry111] - perl-5.34.1 へのアップデート。 #5022 を Fix に。
[xry111] - vim-8.2.4567 (セキュリティフィックス) へのアップデート。 #4500 において言及。
2022-03-05
[xry111] - $LFS/source
の所有者を lfs
に変更しないこととする。
#5018 を Fix に。
[xry111] - zstd-1.5.2 アップストリームの修正パッチを追加。
2022-03-02
[xry111] - meson-0.61.2 へのアップデート。 #5013 を Fix に。
[xry111] - linux-5.16.12 へのアップデート。 #5014 を Fix に。
[xry111] - MarkupSafe-2.1.0 へのアップデート。 #5015 を Fix に。
[xry111] - dbus-1.14.0 へのアップデート。 #5017 を Fix に。
[xry111] - vim-8.2.4489 (セキュリティフィックス) へのアップデート。 #4500 において言及。
[xry111] - GCC 2 回めにおいて libstdc++ をビルドすることとし、個別の libstdc++ 2 回めを削除。
[xry111] - tcl における不要な --enable-64bit
を削除。
2022-03-01
[bdubbs] - LFS-11.1 リリース。
ここに示すのは LFS ブック 11.2-systemd 日本語版 (バージョン 20220901) の変更履歴です。
本節はオリジナルの LFS ブックにはないものです。 LFS ブック日本語版の変更履歴を示すために設けています。
「r11.1-XXX」という表記は、オリジナル LFS ブック GIT 管理ソースの連番号を意味します。 また 6851fc8b2 などのリンクは、オリジナル XML ソースファイルの Git 管理下でのコミットハッシュ値 (その参照ページ) を意味します。
変更履歴
2022-09-01
[matsuand] - LFS 11.2 リリース対応。 r11.1-189 (51b7349a9) までの対応。
2022-08-27
[matsuand] - r11.1-186 (bf6f9e75e) までの対応。
2022-08-26
[matsuand] - r11.1-182 (b3f157c68) までの対応。
2022-08-22
[matsuand] - r11.1-175 (fd6f71bd3) までの対応。
2022-08-20
2022-08-12
[matsuand] - r11.1-166 (c25dd3fc1) までの対応。
2022-08-10
[matsuand] - r11.1-163 (960a230b4) までの対応。
2022-08-07
[matsuand] - r11.1-158 (e06065fc2) までの対応。
2022-07-17
[matsuand] - r11.1-151 (d060b3354) までの対応。
2022-06-25
[matsuand] - r11.1-142 (bfc649552) までの対応。
2022-06-16
[matsuand] - r11.1-135 (c7b29be1c) までの対応。
2022-06-02
[matsuand] - r11.1-133 (9bc47a117) までの対応。
2022-05-17
[matsuand] - r11.1-119 (07b9641ca) までの対応。
2022-05-12
[matsuand] - r11.1-117 (59d5489ff) までの対応。
2022-04-22
[matsuand] - r11.1-92 (93db1e614) までの対応。
2022-04-19
[matsuand] - r11.1-84 (18e99c88b) までの対応。
2022-04-16
[matsuand] - r11.1-76 (1d694184b) までの対応。
2022-04-13
[matsuand] - r11.1-73 (b861051f1) までの対応。
2022-03-31
[matsuand] - r11.1-69 (676f0fdce) までの対応。
2022-03-27
[matsuand] - r11.1-65 (ab7af9e6f) までの対応。
2022-03-25
[matsuand] - r11.1-50 (9b463a215) までの対応。
2022-03-22
[matsuand] - r11.1-44 (53b26d62b) までの対応。
2022-03-17
[matsuand] - r11.1-37 (43149b904) までの対応。
2022-03-15
[matsuand] - r11.1-28 (f7ac150c8) までの対応。
2022-03-05
[matsuand] - r11.1-20 (cb39502e1) までの対応。
2022-03-03
[matsuand] - r11.1-14 (cc2c231b5) までの対応。
2022-03-01
[matsuand] - LFS 11.1 リリース対応。 r11.0-203 (fe09af0cf) まで。
LFS システムの構築作業中にエラー発生したり、疑問を抱いたり、あるいは本書の誤記を発見した場合、まず手始めに https://www.linuxfromscratch.org/faq/ に示されている「よく尋ねられる質問」(Frequently Asked Questions; FAQ) を参照してください。
linuxfromscratch.org
サーバーでは、LFS
開発プロジェクトのために多くのメーリングリストを立ち上げています。
このメーリングリストは主となる開発用とは別に、サポート用のものもあります。 FAQ
だけでは問題解決に至らなかった場合に、次の手としてメーリングリストを検索する以下のサイトを参照してください。
https://www.linuxfromscratch.org/search.html
これ以外に、投稿の方法、アーカイブの配置場所などに関しては https://www.linuxfromscratch.org/mail.html を参照してください。
LFS コミュニティのメンバーの中には、インターネットリレーチャット (Internet Relay Chat; IRC)
によるサポートを行っている者もいます。 ここに対して質問を挙げる場合は、FAQ
やメーリングリストに同様の質問や答えがないかどうかを必ず確認してください。 IRC は irc.libera.chat
において、チャネル名 #lfs-support
により提供しています。
LFS プロジェクトは世界中にミラーサイトがあります。 これらを使えばウェブサイト参照やパッケージのダウンロードがより便利に利用できます。 以下のサイトによりミラーサイトの情報を確認してください。 https://www.linuxfromscratch.org/mirrors.html
本書に基づく作業の中で問題が発生したり疑問が生まれた場合は https://www.linuxfromscratch.org/faq/#generalfaq にある FAQ のページを確認してください。 質問への回答が示されているかもしれません。 そこに回答が示されていなかったなら、問題の本質部分を見極めてください。 トラブルシューティングとして以下のヒントが有用かもしれません。 https://www.linuxfromscratch.org/hints/downloads/files/errors.txt
FAQ では問題解決ができない場合、メーリングリスト https://www.linuxfromscratch.org/search.html を検索してください。
我々のサイトにはメーリングリストやチャットを通じての情報提供を行う LFS コミュニティがあります。 (詳細は 「情報源」を参照してください。) 我々は日々数多くのご質問を頂くのですが、たいていの質問は FAQ やメーリングリストを調べてみれば容易に答えが分かるものばかりです。 したがって我々が最大限の支援を提供できるよう、ある程度の問題はご自身で解決するようにしてください。 そうして頂くことで、我々はもっと特殊な状況に対するサポートを手厚く行っていくことができるからです。 いくら調べても解決に至らず、お問い合わせ頂く場合は、以下に示すように十分な情報を提示してください。
問題が発生し問い合わせをする場合には、以下に示す基本的な情報を含めてください。
お使いの LFS ブックのバージョン。 (本書の場合 11.2-systemd)
LFS 構築に用いたホスト Linux のディストリビューションとそのバージョン。
ホストシステム要件 におけるスクリプトの出力結果。
問題が発生したパッケージまたは本書内の該当の章または節。
問題となったエラーメッセージや状況に対する詳細な情報。
本書どおりに作業しているか、逸脱していないかの情報。
本書の作業手順を逸脱していたとしても、 我々がお手伝いしないわけではありません 。 つまるところ LFS は個人的な趣味によって構築されるものです。 本書の手順とは異なるやり方を正確に説明してください。 そうすれば内容の評価、原因究明が容易になります。
configure
スクリプトの実行時に何か問題が発生した時は config.log
ファイルを確認してみてください。 configure
スクリプトの実行中に、端末画面に表示されないエラーが、このファイルに出力されているかもしれません。 問合せを行う際には
該当する 行を示してください。
コンパイル時に問題が発生した場合は、端末画面への出力とともに、数々のファイルの内容も問題解決の糸口となります。 configure スクリプトと make コマンドの実行によって端末画面に出力される情報は重要です。 問い合わせの際には、出力されるすべての情報を示す必要はありませんが、関連する情報は十分に含めてください。 以下に示すのは make コマンドの実行時に出力される情報を切り出してみた例です。
gcc -DALIASPATH=\"/mnt/lfs/usr/share/locale:.\"
-DLOCALEDIR=\"/mnt/lfs/usr/share/locale\"
-DLIBDIR=\"/mnt/lfs/usr/lib\"
-DINCLUDEDIR=\"/mnt/lfs/usr/include\" -DHAVE_CONFIG_H -I. -I.
-g -O2 -c getopt1.c
gcc -g -O2 -static -o make ar.o arscan.o commands.o dir.o
expand.o file.o function.o getopt.o implicit.o job.o main.o
misc.o read.o remake.o rule.o signame.o variable.o vpath.o
default.o remote-stub.o version.o opt1.o
-lutil job.o: In function `load_too_high':
/lfs/tmp/make-3.79.1/job.c:1565: undefined reference
to `getloadavg'
collect2: ld returned 1 exit status
make[2]: *** [make] Error 1
make[2]: Leaving directory `/lfs/tmp/make-3.79.1'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/lfs/tmp/make-3.79.1'
make: *** [all-recursive-am] Error 2
たいていの方は、上のような場合に終わりの数行しか示してくれません。
make [2]: *** [make] Error 1
問題を解決するにはあまりに不十分な情報です。 そんな情報だけでは「何かがオカしい結果となった」ことは分かっても「なぜオカしい結果となった」のかが分からないからです。 上に示したのは、十分な情報を提供して頂くべきであることを例示したものであり、実行されたコマンドや関連するエラーメッセージが十分に含んだ例となっています。
インターネット上に、問い合わせを行う方法を示した優れた文章があります。 http://catb.org/~esr/faqs/smart-questions.html この文章に示される内容やヒントを参考にして、より確実に回答が得られるよう心がけてください。
この章では LFS システムの構築に必要となるホストツールを確認し、必要に応じてインストールします。 そして LFS システムをインストールするパーティションを準備します。 パーティションを生成しファイルシステムを構築した上で、これをマウントします。
ホストシステムには以下に示すソフトウェアが必要であり、それぞれに示されているバージョン以降である必要があります。 最近の Linux ディストリビューションを利用するなら、あまり問題にはならないはずです。 ディストリビューションによっては、ソフトウェアのヘッダーファイル群を別パッケージとして提供しているものが多々あります。 例えば「<パッケージ名>-devel」であったり「<パッケージ名>-dev」といった具合です。 お使いのディストリビューションがそのような提供の仕方をしている場合は、それらもインストールしてください。
各パッケージにて、示しているバージョンより古いものでも動作するかもしれませんが、テストは行っていません。
Bash-3.2 (/bin/sh が bash に対するシンボリックリンクまたはハードリンクである必要があります。)
Binutils-2.13.1 (2.39 以上のバージョンは、テストしていないためお勧めしません。)
Bison-2.7 (/usr/bin/yacc が bison へのリンクか、bison を実行するためのスクリプトである必要があります。)
Coreutils-6.9
Diffutils-2.8.1
Findutils-4.2.31
Gawk-4.0.1 (/usr/bin/awk が gawk へのリンクである必要があります。)
GCC-4.8 と C++ コンパイラーである g++ (12.2.0 以上のバージョンは、テストしていないためお勧めしません。) ホストされたプログラムを C++ コンパイラーがビルドできるように、C および C++ の標準ライブラリ(ヘッダーを含む)が存在しなければなりません。
Grep-2.5.1a
Gzip-1.3.12
Linux Kernel-3.2
カーネルのバージョンを指定しているのは、第 5 章 と 第 8 章 において、glibc をビルドする際にバージョンを指定するからであり、開発者の勧めに従うためです。 これは udev においても必要になります。
ホストシステムのカーネルバージョンが 3.2 より古い場合は、ここに示した条件に合致するカーネルに置き換えることが必要です。 これを実施するには2つの方法があります。 お使いの Linux システムのベンダーが 3.2 以上のバージョンのカーネルを提供しているかを調べることです。 提供していれば、それをインストールします。 もしそれがない場合や、あったとしてもそれをインストールしたくない場合、カーネルをご自身でコンパイルする必要があります。 カーネルのコンパイルと (ホストシステムが GRUB を利用しているとして) ブートローダーの設定方法については 第 10 章 を参照してください。
M4-1.4.10
Make-4.0
Patch-2.5.4
Perl-5.8.8
Python-3.4
Sed-4.1.5
Tar-1.22
Texinfo-4.7
Xz-5.0.0
上で示しているシンボリックリンクは、本書の説明を通じて LFS を構築するために必要となるものです。 シンボリックリンクが別のソフトウェア (例えば dash や mawk) を指し示している場合でもうまく動作するかもしれません。 しかしそれらに対して LFS 開発チームはテストを行っていませんしサポート対象としていません。 そのような状況に対しては作業手順の変更が必要となり、特定のパッケージに対しては追加のパッチを要するかもしれません。
ホストシステムに、上のソフトウェアの適切なバージョンがインストールされているかどうか、またコンパイルが適切に行えるかどうかは、以下のスクリプトを実行して確認することができます。
cat > version-check.sh << "EOF"
#!/bin/bash
# Simple script to list version numbers of critical development tools
export LC_ALL=C
bash --version | head -n1 | cut -d" " -f2-4
MYSH=$(readlink -f /bin/sh)
echo "/bin/sh -> $MYSH"
echo $MYSH | grep -q bash || echo "ERROR: /bin/sh does not point to bash"
unset MYSH
echo -n "Binutils: "; ld --version | head -n1 | cut -d" " -f3-
bison --version | head -n1
if [ -h /usr/bin/yacc ]; then
echo "/usr/bin/yacc -> `readlink -f /usr/bin/yacc`";
elif [ -x /usr/bin/yacc ]; then
echo yacc is `/usr/bin/yacc --version | head -n1`
else
echo "yacc not found"
fi
echo -n "Coreutils: "; chown --version | head -n1 | cut -d")" -f2
diff --version | head -n1
find --version | head -n1
gawk --version | head -n1
if [ -h /usr/bin/awk ]; then
echo "/usr/bin/awk -> `readlink -f /usr/bin/awk`";
elif [ -x /usr/bin/awk ]; then
echo awk is `/usr/bin/awk --version | head -n1`
else
echo "awk not found"
fi
gcc --version | head -n1
g++ --version | head -n1
grep --version | head -n1
gzip --version | head -n1
cat /proc/version
m4 --version | head -n1
make --version | head -n1
patch --version | head -n1
echo Perl `perl -V:version`
python3 --version
sed --version | head -n1
tar --version | head -n1
makeinfo --version | head -n1 # texinfo version
xz --version | head -n1
echo 'int main(){}' > dummy.c && g++ -o dummy dummy.c
if [ -x dummy ]
then echo "g++ compilation OK";
else echo "g++ compilation failed"; fi
rm -f dummy.c dummy
EOF
bash version-check.sh
LFS は一度にすべてを構築するものとして説明を行っています。 つまり作業途中にシステムをシャットダウンすることは想定していません。 ただこれは、システム構築を立ち止まることなくやり続けろと言っているわけではありません。 LFS 構築を途中から再開する場合には、どの段階からなのかに応じて、特定の作業を再度行うことが必要となります。
これらの章ではホストシステム上で作業を行います。 作業を再開する際には以下に注意します。
2.4 節以降において root
ユーザーにより実行する作業では LFS 環境変数の設定が必要です。 さらにそれはroot
ユーザーにおいて設定されていなければなりません。
/mnt/lfs パーティションがマウントされていることが必要です。
この 2 つの章における処理はすべて、ユーザー lfs
により実施してください。 処理の実施前には
su - lfs
を行ないます。
これをやり忘れた場合、パッケージインストールをホストに対して行ってしまい、利用不能になってしまうリスクがあります。
全般的なコンパイル手順に示す内容は極めて重要です。 パッケージのインストール作業に少しでも疑わしい点があったならば、展開作業を行った tarball やその展開ディレクトリをいったん消去し、再度展開し作業をやり直してください。
/mnt/lfs パーティションがマウントされていることが必要です。
「所有者の変更」から「Chroot
環境への移行」までの操作は、root
ユーザーで行います。 LFS 環境変数が
root
ユーザーにおいて設定されている必要があります。
chroot 環境に入った際には、環境変数 LFS が root
ユーザーにおいて設定されている必要があります。 これ以降
LFS 変数は使いません。
仮想ファイルシステムがマウントされている必要があります。 これは chroot
環境への移行前後において、ホストの仮想端末を変更することで実現します。 root
ユーザーとなって 「/dev のマウントと有効化」 と
「仮想カーネルファイルシステムのマウント」
を実行する必要があります。
どのようなオペレーティングシステムでも同じことが言えますが、本システムでもインストール先は専用のパーティションを用いることにします。 LFS システムを構築していくには、利用可能な空のパーティションか、あるいはパーティション化していないものをパーティションとして生成して利用することにします。
最小限のシステムであれば 10 GB 程度のディスク容量があれば十分です。 これだけあればパッケージやソースの収容に十分で、そこでコンパイル作業を行っていくことができます。 しかし主要なシステムとして LFS を構築するなら、さらにソフトウェアをインストールすることになるはずなので、さらなる容量が必要となります。 30 GB ほどのパーティションがあれば、増量していくことを考えても十分な容量でしょう。 LFS システムそのものがそれだけの容量を要するわけではありません。 これだけの容量は十分なテンポラリ領域のために必要となるものであり、また LFS の完成後に機能追加していくためのものです。 パッケージをインストールした後はテンポラリ領域は開放されますが、コンパイルの間は多くの領域を利用します。
コンパイル処理において十分なランダムアクセスメモリ (Random Access Memory; RAM)
を確保できるとは限りませんので、スワップ (swap
)
領域をパーティションとして設けるのが普通です。
この領域へは利用頻度が低いデータを移すことで、アクティブな処理プロセスがより多くのメモリを確保できるようにカーネルが制御します。
swap
パーティションは、LFS
システムのものとホストシステムのものを共有することもできます。 その場合は新しいパーティションを作る必要はありません。
ディスクのパーティション生成は cfdisk コマンドや fdisk コマンドを使って行います。
コマンドラインオプションにはパーティションを生成するハードディスク名を指定します。 例えばプライマリーディスクであれば
/dev/sda
といったものになります。 そして Linux
ネイティブパーティションと、必要なら swap
パーティションを生成します。 プログラムの利用方法について不明であれば cfdisk(8)
や fdisk(8)
を参照してください。
上級者の方であれば別のパーティション設定も可能です。 最新の LFS システムは、ソフトウェア RAID アレーや、LVM 論理ボリュームを利用することができます。 ただしこれらを実現するには initramfs が必要であり、高度なトピックです。 こういったパーティション設定は、LFS 初心者にはお勧めしません。
新しく生成したパーティションの名前を覚えておいてください。 (例えば sda5
など。) 本書ではこのパーティションを LFS
パーティションとして説明していきます。 また swap
パーティションの名前も忘れないでください。 これらの名前は、後に生成する /etc/fstab
ファイルに記述するために必要となります。
LFS メーリングリストにてパーティションに関する有用情報を望む声をよく聞きます。 これは個人の趣味にもよる極めて主観的なものです。 既存ディストリビューションが採用しているデフォルトのパーティションサイズと言えば、たいていはスワップパーティションを小容量で配置した上で、そのドライブ内の残容量すべてのサイズを割り当てています。 このようなサイズ設定は LFS では最適ではありません。その理由はいくつかあります。 そのようにしてしまうと、複数のディストリビューションの導入時や LFS 構築時に、柔軟さを欠き、構築がしにくくなります。 バックアップを取る際にも無用な時間を要し、ファイルシステム上にて不適当なファイル配置を生み出すため、余計なディスク消費を発生させます。
ルートパーティション (これを /root
ディレクトリと混同しないでください) は 20 GB もあれば、どんなシステムであっても妥当なところでしょう。
それだけあれば LFS 構築も、また BLFS においてもおそらく十分なはずです。
実験的に複数パーティションを設けるとしても、これだけのサイズで十分です。
既存のディストリビューションは、たいていはスワップパーティションを自動的に生成します。 一般にスワップパーティションのサイズは、物理 RAM サイズの二倍の容量とすることが推奨されています。 しかしそれだけの容量はほとんど必要ありません。 ディスク容量が限られているなら、スワップパーティションの容量を 2GB 程度に抑えておいて、ディスクスワップがどれだけ発生するかを確認してみてください。
Linux のハイバーネーション(ディスクへの退避状態)機能を利用する場合、マシンが停止する前に RAM の内容がスワップパーティションに書き出されます。 この場合、スワップパーティションの容量は、システムの RAM 容量と最低でも同程度である必要があります。
スワップは好ましいことではありません。 物理的なハードドライブの場合、スワップが発生しているかどうかは、単純にディスク音を聞いたり、コマンド実行時にシステムがどのように反応するかを見ればわかります。 SSD ドライブの場合、スワップ時の音は聞こえてきません。 その場合は top や free プログラムを使ってスワップ使用量を確認することができます。 SSD ドライブにスワップパーティションを割り当てることは極力避けるべきです。 最初は 5GB くらいのファイルを編集するといった極端なコマンド実行を行ってみて、スワップが起きるかどうかを確認してみてください。 スワップがごく普通に発生するようであれば、RAMを増設するのが適切です。
GUID パーティションテーブル (GUID Partition Table; GPT) を利用して ブートディスク をパーティショニングした場合、普通は 1 MB 程度の小さなパーティションをさらに用意しておくことが必要です。 このパーティションのフォーマットは不要であり、ブートローダーをインストールする際に GRUB が利用できるものでなければなりません。 通常このパーティションは fdisk を用いた場合は 'BIOS Boot' と名付けられます。 また gdisk を用いた場合はEF02 というコード名が与えられます。
Grub バイオスパーティションは、BIOS がシステムブート時に用いるドライブ上になければなりません。 これは LFS ルートパーティションがあるドライブと同一にする必要はありません。 システム上にあるドライブは、同一のパーティションテーブルタイプを利用していないことがあります。 つまりこの Grub バイオスパーティションに必要なのは、ブートディスクのパーティションテーブルタイプに合わせることだけです。
この他にも、必要のないパーティションというものがいくつかあります。 しかしディスクレイアウトを取り決めるには考えておく必要があります。 以下に示すのは十分な説明ではありませんが、一つの目安として示すものです。
/boot – 作成することが強く推奨されます。 カーネルやブート情報を収納するために利用するパーティションです。 容量の大きなディスクの場合、ブート時に問題が発生することがあるので、これを回避するには、一つ目のディスクドライブの物理的に一番最初のパーティションを選びます。 パーティションサイズを 200MB とすればそれで十分です。
/boot/efi – EFI システムパーティションであり、UEFI を使ってシステム起動する場合に必要です。 詳しくは BLFS ページ を参照してください。
/home – 作成することが強く推奨されます。 複数のディストリビューションや LFS の間で、ホームディレクトリおよびユーザー固有の設定を共有することができます。 パーティションサイズは、ある程度大きく取ることになりますが、利用可能なディスク残容量に依存します。
/usr – LFS においては /bin
,
/lib
, /sbin
の各ディレクトリは、/usr
配下からのシンボリックリンクとしています。 したがって
/usr
には、システムを動作させるために必要となる実行モジュールがすべて置かれます。 LFS において
/usr
を別パーティションとすることは、普通は不要です。
それでもこれが必要となる場合、システム内のプログラムやライブラリすべてが収容できるように、そのパーティション容量を十分に確保することが必要です。
root パーティションは、このような設定とするなら、極端に小さなサイズ(1
ギガバイト程度)でも十分です。 これはシンクライアントやディスクなしワークステーションに適しています。
(そういった環境では /usr
がリモートサーバーにマウントされます。) ただし(LFS では対応していない)initramfs
を利用する際には、これがブートする際に /usr
が別パーティションになっていることが必要であるため、注意してください。
/opt – このディレクトリは BLFS などにおいて、Gnome や KDE といった巨大なパッケージをいくつもインストールする際に活用されます。 /usr ディレクトリ以外にインストールする場合です。 これを別パーティションとするなら、一般的には 5 ~ 10 GB 程度が適当でしょう。
/tmp – /tmp ディレクトリを別パーティションとするのは普通は行いません。 ただしシンクライアント (thin client) では有効です。 別パーティションとする場合であっても、数GB程度あれば十分です。
/usr/src – このパーティションは LFS のパッケージソースを収容し LFS ビルド工程にて共用するものとして有効に利用することができます。 さらに BLFS パッケージソースを収容しビルドする場所としても利用可能です。 30~50GBくらいの容量があれば、十分なものです。
ブート時に自動的にパーティションをマウントしたい場合は /etc/fstab
ファイルにて設定します。 パーティションの設定方法については
「/etc/fstab
ファイルの生成」で説明しています。
空のパーティションが準備できたのでファイルシステムを作ります。 LFS では Linux カーネルが識別できるならどのようなファイルシステムを用いるのでも構いません。 ただ最も標準的なものとして ext3 と ext4 があります。 ファイルシステムをどのようにするかは単純な話ではなく、収容するファイルの性質やパーティションサイズにも依存します。 例えば以下のとおりです。
比較的小容量のパーティションで、/boot のようにあまり更新されないパーティションに対して適してます。
ext2 の拡張でありジャーナルを含みます。 このジャーナルとは、不測のシャットダウン時などに、パーティション状態の復元に用いられます。 汎用的なファイルシステムとして用いることができます。
パーティションタイプとして用いられる ext 系の最新バージョンです。 新たな機能として、ナノ秒単位のタイムスタンプの提供、大容量ファイル (16 TB) の生成利用、処理性能の改善が加えられています。
この他のファイルシステムとして、FAT32, NTFS, ReiserFS, JFS, XFS などがあり、それぞれに特定の目的に応じて活用されています。 ファイルシステムの詳細については http://en.wikipedia.org/wiki/Comparison_of_file_systems を参照してください。
LFS ではルートファイルシステム (/) として ext4 を用いるものとします。 LFS 用のパーティションに対して
ext4
ファイルシステムを生成するために以下のコマンドを実行します。
mkfs -v -t ext4 /dev/<xxx>
<xxx>
の部分は LFS
パーティション名に合わせて置き換えてください。
既存の swap
パーティションを利用している場合は、初期化を行う必要はありません。 新しく swap
パーティションを生成した場合には、以下のコマンドにより初期化を行ってください。
mkswap /dev/<yyy>
<yyy>
の部分は
swap
パーティションの名に合わせて置き換えてください。
本書の中では環境変数 LFS
を何度も用います。 LFS
システムのビルド作業時には常に定義しておくことを忘れないでください。 この変数は LFS
パーティションとして選んだマウントポイントを定義します。 例えば /mnt/lfs
というものです。 他のものとしても構いません。 LFS
を別のパーティションにビルドする場合、このマウントポイントはそのパーティションを示すようにしてください。
ディレクトリを取り決めたら、変数を以下のコマンドにより設定します。
export LFS=/mnt/lfs
上のように変数を定義しておくと、例えば mkdir $LFS/tools といったコマンドを、この通りに入力することで実行できるので便利です。 これが実行されると、シェルが「$LFS」を「/mnt/lfs」に (あるいは変数にセットされている別のディレクトリに) 置換して処理してくれます。
$LFS
が常にセットされていることを忘れずに確認してください。
特に、別ユーザーでログインし直した場合 (su コマンドによって root
ユーザーや別のユーザーでログインした場合)
には、忘れずに確認してください。
echo $LFS
上の出力結果が LFS システムのビルドディレクトリであることを確認してください。 本書に示す例に従っている場合は
/mnt/lfs
が表示されるはずです。
出力が正しくない場合は、冒頭に示したコマンド実行により $LFS
変数に正しいディレクトリを設定してください。
LFS
変数を確実に設定しておくために、ローカルな
.bash_profile
および /root/.bash_profile
に上記変数を export
するコマンドを記述しておく方法もあります。 なお /etc/passwd
ファイルにて LFS
変数を必要とするユーザーは、シェルとして bash を利用するようにしてください。
/root/.bash_profile
ファイルはログインプロセスの一部として機能するためです。
もう一つ気にかけることとして、ホストシステム上にログ出力を行う方法に関してです。
グラフィカルディスプレイマネージャーを通じてログ出力を行うと、仮想端末が起動する際に、ユーザー独自の
.bash_profile
は普通は用いられません。
この場合は、各ユーザー用と root
用の
.bashrc
に export コマンドを追加してください。
ここでディストリビューションの中には、非対話形式での bash の実行時には .bashrc
を実行しないように求めているものがあります。
その場合は、非対話形式の利用をテストする前に export コマンドを追加してください。
ファイルシステムが生成できたら、パーティションをアクセスできるようにします。
これを行うためにはマウントポイントを定める必要があります。 本書では前に示したように、環境変数 LFS
に指定されたディレクトリに対してファイルシステムがマウントされるものとします。
マウントポイントを生成し、LFS ファイルシステムをマウントします。
mkdir -pv $LFS
mount -v -t ext4 /dev/<xxx>
$LFS
<xxx>
の部分は LFS
パーティション名に合わせて置き換えてください。
LFS に対して複数のパーティションを用いる場合 (例えば /
と
/home
が別パーティションである場合)
は、以下を実行してそれぞれをマウントします。
mkdir -pv $LFS mount -v -t ext4 /dev/<xxx>
$LFS mkdir -v $LFS/home mount -v -t ext4 /dev/<yyy>
$LFS/home
<xxx>
や
<yyy>
の部分は、それぞれ適切なパーティション名に置き換えてください。
この新しいパーティションは特別な制限オプション (nosuid
、nodev
など)
は設定せずにマウントします。 mount
コマンドの実行時に引数を与えずに実行すれば、LFS
パーティションがどのようなオプション設定によりマウントされているかが分かります。 もし nosuid
、nodev
オプションが設定されていたら、マウントし直してください。
上で説明した内容は、LFS 構築作業においてコンピューターを再起動しない場合の話です。 コンピューターを一度シャットダウンした場合は、LFS 構築作業の再開のたびに LFS パーティションを再マウントする必要があります。 あるいはブート時に自動マウントをしたいのであれば、ホストシステムの /etc/fstab ファイルを書き換えておく必要があります。 書き換えは例えば以下のようになります。
/dev/<xxx>
/mnt/lfs ext4 defaults 1 1
追加のパーティションを利用している場合は、それらを書き加えることも忘れないでください。
swap
パーティションを用いる場合は、swapon
コマンドを使って利用可能にしてください。
/sbin/swapon -v /dev/<zzz>
<zzz>
の部分は
swap
パーティション名に置き換えてください。
こうして動作環境が整いました。次はパッケージのダウンロードです。
この章では基本的な Linux システム構築のためにダウンロードするべきパッケージの一覧を示します。 各パッケージのバージョンは動作が確認されているものを示しており、本書ではこれに基づいて説明します。 LFS errata やセキュリティアドバイザリーに示されていれば別ですが、ここに示すバージョンとは異なるものは使わないようお勧めします。 あるバージョンでビルドしたコマンドが、違うバージョンで動作する保証はないからです。 最新のパッケージの場合、何かの対処を要するかもしれません。 そのような対処方法は本書の開発版において開発され安定化が図られるかもしれません。
パッケージによっては、リリース tarball に加えて (Git や SVN の) リポジトリスナップショット tarball があって、両者を同じファイル名で提供している場合があります。 リリース tarball には、該当するリポジトリスナップショットの内容に加えて生成済みファイル(たとえば autoconf が作り出す configure スクリプト)が含まれます。 本書では可能な限りリリース tarball を用いることにします。 本書が指定するリリース tarball ではなく、リポジトリスナップショットを利用すると、問題が発生するかもしれません。
ダウンロードサイトは常にアクセス可能であるとは限りません。 本書が提供された後にダウンロードする場所が変更になっていたら Google (http://www.google.com/) を使って検索してみてください。 たいていのパッケージを見つけ出すことが出来るはずです。 それでも見つけられなかったら https://www.linuxfromscratch.org/lfs/packages.html#packages から入手してください。
ダウンロードしたパッケージやパッチは、ビルド作業を通じて常に利用可能な場所を選んで保存しておく必要があります。
またソース類を伸張してビルドを行うための作業ディレクトリも必要です。 そこで本書では $LFS/sources
ディレクトリを用意し、ソースやパッチの保存場所とし、そこでビルドを行う作業ディレクトリとします。 このディレクトリにしておけば
LFS パーティションに位置することから LFS ビルドを行う全工程において常に利用することが出来ます。
ダウンロードを行う前にまずはそのようなディレクトリを生成します。 root
ユーザーとなって以下のコマンドを実行します。
mkdir -v $LFS/sources
このディレクトリには書き込み権限とスティッキーを与えます。 「スティッキー (Sticky) 」は複数ユーザーに対して書き込み権限が与えられても、削除については所有者しか実行出来ないようにします。 以下のコマンドによって書き込み権限とスティッキーを定めます。
chmod -v a+wt $LFS/sources
LFS のビルドに必要なパッケージやパッチを得る方法は、いろいろとあります。
各ファイルは次の2節に示されているので、個々に入手することができます。
本書の安定版であれば、それに対して必要となるファイルを集めた tarball が、https://www.linuxfromscratch.org/mirrors.html#files に示す LFS ミラーサイトからダウンロードできます。
wget と以下に示す wget-list ファイルを利用すれば、すべてのファイルをダウンロードすることができます。
パッケージとパッチのダウンロードを行うため wget-list を利用することにします。 これは以下のように wget コマンドの入力引数に指定します。
wget --input-file=wget-list-systemd --continue --directory-prefix=$LFS/sources
オリジナルの LFS ブックでは、wget-list 内に含まれる、各種パッケージの入手 URL が主に米国サイトとなっています。 一方、日本国内にて作業する方であれば、例えば GNU のパッケージ類は国内に数多くのミラーサイトが存在するため、そちらから取得するのが適切でしょう。 これはネットワークリソースを利用する際のマナーとも言えるものです。 堅苦しい話をするつもりはありません。 国内サイトから入手することにすればダウンロード速度が断然早くなります。 メリットは大きいと思いますのでお勧めします。
国内から入手可能なものは国内から入手することを目指し、訳者は以下の手順により wget-list を書き換えて利用しています。 一例として国内には理化学研究所のサイト (ftp.riken.jp) があります。 そこでは GNU パッケージ類がミラー提供されています。 そこで wget-list にて ftp.gnu.org を指し示している URL を ftp.riken.jp に置き換えます。 また同じ方法で Linux カーネル、Perl、Vim の入手先も変更します。
cat > wl.sed << "EOF"
s|ftp\.gnu\.org/gnu/|ftp.riken.jp/GNU/|g
s|https://www\.kernel\.org/pub/linux/|http://ftp.riken.jp/Linux/kernel.org/linux/|g
s|www\.cpan\.org|ftp.riken.jp/lang/CPAN|g
s|ftp\.vim\.org|ftp.jp.vim.org|g
EOF
sed -f wl.sed -i.orig wget-list-systemd
rm wl.sed
上記はあくまで一例です。しかもすべてのパッケージについて、国内サイトからの入手となるわけではありません。 ただし上記を行うだけでも、大半のパッケージは国内サイトを向くことになります。 上記にて国内のミラーサイトは、ネットワーク的に "より近い" ものを選んでください。 サイトを変えた場合は、パッケージの URL が異なることが多々あるため、適宜 sed 置換内容を書き換えてください。
注意する点として各パッケージが更新されたばかりの日付では、国内ミラーサイトへの同期、反映が間に合わず、ソース類が存在しないことが考えられます。 その場合にはパッケージ取得に失敗してしまいます。 そこで wget-list と wget-list.orig を順に利用し、かつ wget コマンドにて -N オプションを使って (取得済のものはスキップするようにして) 以下のコマンドを実行すれば、確実にすべてのパッケージを入手することができます。
wget -N --input-file=wget-list-systemd --continue --directory-prefix=$LFS/sources wget -N --input-file=wget-list-systemd.orig --continue --directory-prefix=$LFS/sources
さらに LFS-7.0 からは md5sums
というファイルを用意しています。
このファイルは、入手した各種パッケージのファイルが正しいことを確認するために用いることができます。 このファイルを
$LFS/sources
に配置して以下を実行してください。
pushd $LFS/sources md5sum -c md5sums popd
必要なファイルを入手した方法が前述のどの方法であっても、この md5sum チェックを実施することができます。
パッケージをダウンロードする前には セキュリティアドバイス(security advisories)を読んでください。 セキュリティぜい弱性を回避するためにパッケージの最新バージョンがないかどうかを確認してください。
アップストリームでは、古いリリースを削除していることがあります。 特にそのリリースにセキュリティぜい弱性を含んでいた場合です。 以下に示す URL が無効になっていたら、まず初めにセキュリティアドバイスを読んでください。 そして新たなバージョンが(ぜい弱性を解消して)入手できるかどうかを確認してください。 それでもパッケージが削除されてしまっている場合は、ミラーサイトからのダウンロードを試してみてください。 ぜい弱性が原因で削除されていた古いバージョンのパッケージがダウンロードできたとしても、ぜい弱性に問題があるのであれば、システムビルドに用いることはお勧めしません。
以下に示すパッケージをダウンロードするなどしてすべて入手してください。
ホームページ: https://savannah.nongnu.org/projects/acl
ダウンロード: https://download.savannah.gnu.org/releases/acl/acl-2.3.1.tar.xz
MD5 sum: 95ce715fe09acca7c12d3306d0f076b2
ホームページ: https://savannah.nongnu.org/projects/attr
ダウンロード: https://download.savannah.gnu.org/releases/attr/attr-2.5.1.tar.gz
MD5 sum: ac1c5a7a084f0f83b8cace34211f64d8
ホームページ: https://www.gnu.org/software/autoconf/
ダウンロード: https://ftp.gnu.org/gnu/autoconf/autoconf-2.71.tar.xz
MD5 sum: 12cfa1687ffa2606337efe1a64416106
ホームページ: https://www.gnu.org/software/automake/
ダウンロード: https://ftp.gnu.org/gnu/automake/automake-1.16.5.tar.xz
MD5 sum: 4017e96f89fca45ca946f1c5db6be714
SHA256 sum: 80facc09885a57e6d49d06972c0ae1089c5fa8f4d4c7cfe5baea58e5085f136d
ホームページ: https://www.gnu.org/software/bash/
ダウンロード: https://ftp.gnu.org/gnu/bash/bash-5.1.16.tar.gz
MD5 sum: c17b20a09fc38d67fb303aeb6c130b4e
ホームページ: https://git.yzena.com/gavin/bc
ダウンロード: https://github.com/gavinhoward/bc/releases/download/6.0.1/bc-6.0.1.tar.xz
MD5 sum: 4c8b8d51eb52ee66f5bcf6a6a1ca576e
ホームページ: https://www.gnu.org/software/binutils/
ダウンロード: https://ftp.gnu.org/gnu/binutils/binutils-2.39.tar.xz
MD5 sum: f7e986ae9ff06405cafb2e585ee36d27
ホームページ: https://www.gnu.org/software/bison/
ダウンロード: https://ftp.gnu.org/gnu/bison/bison-3.8.2.tar.xz
MD5 sum: c28f119f405a2304ff0a7ccdcc629713
ダウンロード: https://www.sourceware.org/pub/bzip2/bzip2-1.0.8.tar.gz
MD5 sum: 67e051268d0c475ea773822f7500d0e5
ホームページ: https://libcheck.github.io/check
ダウンロード: https://github.com/libcheck/check/releases/download/0.15.2/check-0.15.2.tar.gz
MD5 sum: 50fcafcecde5a380415b12e9c574e0b2
ホームページ: https://www.gnu.org/software/coreutils/
ダウンロード: https://ftp.gnu.org/gnu/coreutils/coreutils-9.1.tar.xz
MD5 sum: 8b1ca4e018a7dce9bb937faec6618671
ホームページ: https://www.freedesktop.org/wiki/Software/dbus
ダウンロード: https://dbus.freedesktop.org/releases/dbus/dbus-1.14.0.tar.xz
MD5 sum: ddd5570aff05191dbee8e42d751f1b7d
ホームページ: https://www.gnu.org/software/dejagnu/
ダウンロード: https://ftp.gnu.org/gnu/dejagnu/dejagnu-1.6.3.tar.gz
MD5 sum: 68c5208c58236eba447d7d6d1326b821
ホームページ: https://www.gnu.org/software/diffutils/
ダウンロード: https://ftp.gnu.org/gnu/diffutils/diffutils-3.8.tar.xz
MD5 sum: 6a6b0fdc72acfe3f2829aab477876fbc
ホームページ: http://e2fsprogs.sourceforge.net/
ダウンロード: https://downloads.sourceforge.net/project/e2fsprogs/e2fsprogs/v1.46.5/e2fsprogs-1.46.5.tar.gz
MD5 sum: 3da91854c960ad8a819b48b2a404eb43
ホームページ: https://sourceware.org/elfutils/
ダウンロード: https://sourceware.org/ftp/elfutils/0.187/elfutils-0.187.tar.bz2
MD5 sum: cc04f07b53a71616b22553c0a458cf4b
ホームページ: https://libexpat.github.io/
ダウンロード: https://prdownloads.sourceforge.net/expat/expat-2.4.8.tar.xz
MD5 sum: 0584a7318a4c007f7ec94778799d72fe
ホームページ: https://core.tcl.tk/expect/
ダウンロード: https://prdownloads.sourceforge.net/expect/expect5.45.4.tar.gz
MD5 sum: 00fce8de158422f5ccd2666512329bd2
ホームページ: https://www.darwinsys.com/file/
ダウンロード: https://astron.com/pub/file/file-5.42.tar.gz
MD5 sum: 4d4f70c3b08a8a70d8baf67f085d7e92
ホームページ: https://www.gnu.org/software/findutils/
ダウンロード: https://ftp.gnu.org/gnu/findutils/findutils-4.9.0.tar.xz
MD5 sum: 4a4a547e888a944b2f3af31d789a1137
ホームページ: https://github.com/westes/flex
ダウンロード: https://github.com/westes/flex/releases/download/v2.6.4/flex-2.6.4.tar.gz
MD5 sum: 2882e3179748cc9f9c23ec593d6adc8d
ホームページ: https://www.gnu.org/software/gawk/
ダウンロード: https://ftp.gnu.org/gnu/gawk/gawk-5.1.1.tar.xz
MD5 sum: 83650aa943ff2fd519b2abedf8506ace
ホームページ: https://gcc.gnu.org/
ダウンロード: https://ftp.gnu.org/gnu/gcc/gcc-12.2.0/gcc-12.2.0.tar.xz
MD5 sum: 73bafd0af874439dcdb9fc063b6fb069
SHA256 sum:
ホームページ: https://www.gnu.org/software/gdbm/
ダウンロード: https://ftp.gnu.org/gnu/gdbm/gdbm-1.23.tar.gz
MD5 sum: 8551961e36bf8c70b7500d255d3658ec
ホームページ: https://www.gnu.org/software/gettext/
ダウンロード: https://ftp.gnu.org/gnu/gettext/gettext-0.21.tar.xz
MD5 sum: 40996bbaf7d1356d3c22e33a8b255b31
ホームページ: https://www.gnu.org/software/libc/
ダウンロード: https://ftp.gnu.org/gnu/glibc/glibc-2.36.tar.xz
MD5 sum: 00e9b89e043340f688bc93ec03239b57
ホームページ: https://www.gnu.org/software/gmp/
ダウンロード: https://ftp.gnu.org/gnu/gmp/gmp-6.2.1.tar.xz
MD5 sum: 0b82665c4a92fd2ade7440c13fcaa42b
ホームページ: https://www.gnu.org/software/gperf/
ダウンロード: https://ftp.gnu.org/gnu/gperf/gperf-3.1.tar.gz
MD5 sum: 9e251c0a618ad0824b51117d5d9db87e
ホームページ: https://www.gnu.org/software/grep/
ダウンロード: https://ftp.gnu.org/gnu/grep/grep-3.7.tar.xz
MD5 sum: 7c9cca97fa18670a21e72638c3e1dabf
ホームページ: https://www.gnu.org/software/groff/
ダウンロード: https://ftp.gnu.org/gnu/groff/groff-1.22.4.tar.gz
MD5 sum: 08fb04335e2f5e73f23ea4c3adbf0c5f
ホームページ: https://www.gnu.org/software/grub/
ダウンロード: https://ftp.gnu.org/gnu/grub/grub-2.06.tar.xz
MD5 sum: cf0fd928b1e5479c8108ee52cb114363
ホームページ: https://www.gnu.org/software/gzip/
ダウンロード: https://ftp.gnu.org/gnu/gzip/gzip-1.12.tar.xz
MD5 sum: 9608e4ac5f061b2a6479dc44e917a5db
ホームページ: https://www.iana.org/protocols
ダウンロード: https://github.com/Mic92/iana-etc/releases/download/20220812/iana-etc-20220812.tar.gz
MD5 sum: 851a53efd53c77d0ad7b3d2b68d8a3fc
ホームページ: https://www.gnu.org/software/inetutils/
ダウンロード: https://ftp.gnu.org/gnu/inetutils/inetutils-2.3.tar.xz
MD5 sum: e73e2ed42d73ceb47616b20131236036
SHA256 sum:
ホームページ: https://freedesktop.org/wiki/Software/intltool
ダウンロード: https://launchpad.net/intltool/trunk/0.51.0/+download/intltool-0.51.0.tar.gz
MD5 sum: 12e517cac2b57a0121cda351570f1e63
ホームページ: https://www.kernel.org/pub/linux/utils/net/iproute2/
ダウンロード: https://www.kernel.org/pub/linux/utils/net/iproute2/iproute2-5.19.0.tar.xz
MD5 sum: 415bd9eeb8515a585e245809d2fe45a6
ホームページ: https://jinja.palletsprojects.com/en/3.0.x/
ダウンロード: https://files.pythonhosted.org/packages/source/J/Jinja2/Jinja2-3.1.2.tar.gz
MD5 sum: d31148abd89c1df1cdb077a55db27d02
ホームページ: https://kbd-project.org/
ダウンロード: https://www.kernel.org/pub/linux/utils/kbd/kbd-2.5.1.tar.xz
MD5 sum: 10f10c0a9d897807733f2e2419814abb
ダウンロード: https://www.kernel.org/pub/linux/utils/kernel/kmod/kmod-30.tar.xz
MD5 sum: 85202f0740a75eb52f2163c776f9b564
ホームページ: https://www.greenwoodsoftware.com/less/
ダウンロード: https://www.greenwoodsoftware.com/less/less-590.tar.gz
MD5 sum: f029087448357812fba450091a1172ab
ホームページ: https://sites.google.com/site/fullycapable/
ダウンロード: https://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/libcap-2.65.tar.xz
MD5 sum: 3543e753dd941255c4def6cc67a462bb
ホームページ: https://sourceware.org/libffi/
ダウンロード: https://github.com/libffi/libffi/releases/download/v3.4.2/libffi-3.4.2.tar.gz
MD5 sum: 294b921e6cf9ab0fbaea4b639f8fdbe8
ホームページ: http://libpipeline.nongnu.org/
ダウンロード: https://download.savannah.gnu.org/releases/libpipeline/libpipeline-1.5.6.tar.gz
MD5 sum: 829c9ba46382b0b3e12dd11fcbc1bb27
ホームページ: https://www.gnu.org/software/libtool/
ダウンロード: https://ftp.gnu.org/gnu/libtool/libtool-2.4.7.tar.xz
MD5 sum: 2fc0b6ddcd66a89ed6e45db28fa44232
ホームページ: https://www.kernel.org/
ダウンロード: https://www.kernel.org/pub/linux/kernel/v5.x/linux-5.19.2.tar.xz
MD5 sum: 391274e2e49a881403b0ff2e0712bf82
Linux カーネルはわりと頻繁に更新されます。 多くの場合はセキュリティ脆弱性の発見によるものです。 特に正誤情報 (errata) のページにて説明がない限りは、入手可能な最新安定版のカーネルを用いてください。 あるいは errata に指示があればそれに従ってください。
低速度のネットワークや高負荷の帯域幅を利用するユーザーが Linux カーネルをアップデートしようとする場合は、同一バージョンのカーネルパッケージとそのパッチを個別にダウンロードする方法もあります。 その場合、時間の節約を図ることができ、あるいはマイナーバージョンが同一であれば複数パッチを当ててアップグレードする作業時間の短縮が図れます。
ホームページ: https://www.gnu.org/software/m4/
ダウンロード: https://ftp.gnu.org/gnu/m4/m4-1.4.19.tar.xz
MD5 sum: 0d90823e1426f1da2fd872df0311298d
ホームページ: https://www.gnu.org/software/make/
ダウンロード: https://ftp.gnu.org/gnu/make/make-4.3.tar.gz
MD5 sum: fc7a67ea86ace13195b0bce683fd4469
ホームページ: https://www.nongnu.org/man-db/
ダウンロード: https://download.savannah.gnu.org/releases/man-db/man-db-2.10.2.tar.xz
MD5 sum: e327f7af3786d15e5851658ae7ef47ed
ホームページ: https://www.kernel.org/doc/man-pages/
ダウンロード: https://www.kernel.org/pub/linux/docs/man-pages/man-pages-5.13.tar.xz
MD5 sum: 3ac24e8c6fae26b801cb87ceb63c0a30
ホームページ: https://palletsprojects.com/p/markupsafe/
ダウンロード: https://files.pythonhosted.org/packages/source/M/MarkupSafe/MarkupSafe-2.1.1.tar.gz
MD5 sum: 9809f9fdd98bc835b0c21aa8f79cbf30
ホームページ: https://mesonbuild.com
ダウンロード: https://github.com/mesonbuild/meson/releases/download/0.63.1/meson-0.63.1.tar.gz
MD5 sum: 078e59d11a72b74c3bd78cb8205e9ed7
ホームページ: http://www.multiprecision.org/
ダウンロード: https://ftp.gnu.org/gnu/mpc/mpc-1.2.1.tar.gz
MD5 sum: 9f16c976c25bb0f76b50be749cd7a3a8
ホームページ: https://www.mpfr.org/
ダウンロード: https://ftp.gnu.org/gnu/mpfr/mpfr-4.1.0.tar.xz
MD5 sum: bdd3d5efba9c17da8d83a35ec552baef
ホームページ: https://www.gnu.org/software/ncurses/
ダウンロード: https://invisible-mirror.net/archives/ncurses/ncurses-6.3.tar.gz
MD5 sum: a2736befde5fee7d2b7eb45eb281cdbe
ホームページ: https://ninja-build.org/
ダウンロード: https://github.com/ninja-build/ninja/archive/v1.11.0/ninja-1.11.0.tar.gz
MD5 sum: 7d1a1a2f5cdc06795b3054df5c17d5ef
ホームページ: https://www.openssl.org/
ダウンロード: https://www.openssl.org/source/openssl-3.0.5.tar.gz
MD5 sum: 163bb3e58c143793d1dc6a6ec7d185d5
ホームページ: https://savannah.gnu.org/projects/patch/
ダウンロード: https://ftp.gnu.org/gnu/patch/patch-2.7.6.tar.xz
MD5 sum: 78ad9937e4caadcba1526ef1853730d5
ホームページ: https://www.perl.org/
ダウンロード: https://www.cpan.org/src/5.0/perl-5.36.0.tar.xz
MD5 sum: 826e42da130011699172fd655e49cfa2
ホームページ: https://www.freedesktop.org/wiki/Software/pkg-config
ダウンロード: https://pkg-config.freedesktop.org/releases/pkg-config-0.29.2.tar.gz
MD5 sum: f6e931e319531b736fadc017f470e68a
ホームページ: https://sourceforge.net/projects/procps-ng
ダウンロード: https://sourceforge.net/projects/procps-ng/files/Production/procps-ng-4.0.0.tar.xz
MD5 sum: eedf93f2f6083afb7abf72188018e1e5
ホームページ: https://gitlab.com/psmisc/psmisc
ダウンロード: https://sourceforge.net/projects/psmisc/files/psmisc/psmisc-23.5.tar.xz
MD5 sum: 014f0b5d5ab32478a2c57812ad01e1fb
ホームページ: https://www.python.org/
ダウンロード: https://www.python.org/ftp/python/3.10.6/Python-3.10.6.tar.xz
MD5 sum: afc7e14f7118d10d1ba95ae8e2134bf0
ダウンロード: https://www.python.org/ftp/python/doc/3.10.6/python-3.10.6-docs-html.tar.bz2
MD5 sum: 8f32c4f4f0b18ec56e8b3822bbaeb017
ホームページ: https://tiswww.case.edu/php/chet/readline/rltop.html
ダウンロード: https://ftp.gnu.org/gnu/readline/readline-8.1.2.tar.gz
MD5 sum: 12819fa739a78a6172400f399ab34f81
ホームページ: https://www.gnu.org/software/sed/
ダウンロード: https://ftp.gnu.org/gnu/sed/sed-4.8.tar.xz
MD5 sum: 6d906edfdb3202304059233f51f9a71d
ホームページ: https://shadow-maint.github.io/shadow/
ダウンロード: https://github.com/shadow-maint/shadow/releases/download/4.12.2/shadow-4.12.2.tar.xz
MD5 sum: 52637cb34c357acf85c617cf95da34a6
ホームページ: https://www.freedesktop.org/wiki/Software/systemd/
ダウンロード: https://github.com/systemd/systemd/archive/v251/systemd-251.tar.gz
MD5 sum: 8090fcccc3a2ec20995e89d56fed61b1
ホームページ: https://www.freedesktop.org/wiki/Software/systemd/
ダウンロード: https://anduin.linuxfromscratch.org/LFS/systemd-man-pages-251.tar.xz
MD5 sum: 87053ffef1cfb74e4fe28f627e12a2a4
Linux From Scratch チームは、systemd ソースにおいて提供される man ページの tarball を独自に生成しています。 これは、不要な依存関係を取り除くためです。
ホームページ: https://www.gnu.org/software/tar/
ダウンロード: https://ftp.gnu.org/gnu/tar/tar-1.34.tar.xz
MD5 sum: 9a08d29a9ac4727130b5708347c0f5cf
ホームページ: http://tcl.sourceforge.net/
ダウンロード: https://downloads.sourceforge.net/tcl/tcl8.6.12-src.tar.gz
MD5 sum: 87ea890821d2221f2ab5157bc5eb885f
ダウンロード: https://downloads.sourceforge.net/tcl/tcl8.6.12-html.tar.gz
MD5 sum: a0d1a5b60bbb68f2f0bd3066a19c527a
ホームページ: https://www.gnu.org/software/texinfo/
ダウンロード: https://ftp.gnu.org/gnu/texinfo/texinfo-6.8.tar.xz
MD5 sum: a91b404e30561a5df803e6eb3a53be71
ホームページ: https://www.iana.org/time-zones
ダウンロード: https://www.iana.org/time-zones/repository/releases/tzdata2022c.tar.gz
MD5 sum: 4e3b2369b68e713ba5d3f7456f20bfdb
ホームページ: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/
ダウンロード: https://www.kernel.org/pub/linux/utils/util-linux/v2.38/util-linux-2.38.1.tar.xz
MD5 sum: cd11456f4ddd31f7fbfdd9488c0c0d02
ホームページ: https://www.vim.org
ダウンロード: https://anduin.linuxfromscratch.org/LFS/vim-9.0.0228.tar.gz
MD5 sum: bc7e0a4829d94bb4c03a7a6b4ad6a8cf
vim のバージョンは日々更新されます。 最新版を入手するには https://github.com/vim/vim/tags にアクセスしてください。
ホームページ: https://pypi.org/project/wheel/
ダウンロード: https://anduin.linuxfromscratch.org/LFS/wheel-0.37.1.tar.gz
MD5 sum: f490f1399e5903706cb1d4fbed9ecb28
ホームページ: https://github.com/chorny/XML-Parser
ダウンロード: https://cpan.metacpan.org/authors/id/T/TO/TODDR/XML-Parser-2.46.tar.gz
MD5 sum: 80bb18a8e6240fcf7ec2f7b57601c170
ホームページ: https://tukaani.org/xz
ダウンロード: https://tukaani.org/xz/xz-5.2.6.tar.xz
MD5 sum: d9cd5698e1ec06cf638c0d2d645e8175
ホームページ: https://www.zlib.net/
ダウンロード: https://zlib.net/zlib-1.2.12.tar.xz
MD5 sum: 28687d676c04e7103bb6ff2b9694c471
ホームページ: https://facebook.github.io/zstd/
ダウンロード: https://github.com/facebook/zstd/releases/download/v1.5.2/zstd-1.5.2.tar.gz
MD5 sum: 072b10f71f5820c24761a65f31f43e73
全パッケージのサイズ合計: 約 472 MB
パッケージに加えて、いくつかのパッチも必要となります。 それらのパッチはパッケージの不備をただすもので、本来なら開発者が修正すべきものです。 パッチは不備修正だけでなく、ちょっとした修正を施して扱いやすいものにする目的のものもあります。 以下に示すものが LFS システム構築に必要となるパッチすべてです。
各パッチに付けられている簡略な名称については、訳出せずそのまま表記することにします。
ダウンロード: https://www.linuxfromscratch.org/patches/lfs/11.2/bzip2-1.0.8-install_docs-1.patch
MD5 sum: 6a5ac7e89b791aae556de0f745916f7f
ダウンロード: https://www.linuxfromscratch.org/patches/lfs/11.2/coreutils-9.1-i18n-1.patch
MD5 sum: c1ac7edf095027460716577633da9fc5
ダウンロード: https://www.linuxfromscratch.org/patches/lfs/11.2/glibc-2.36-fhs-1.patch
MD5 sum: 9a5997c3452909b1769918c759eff8a2
ダウンロード: https://www.linuxfromscratch.org/patches/lfs/11.2/kbd-2.5.1-backspace-1.patch
MD5 sum: f75cca16a38da6caa7d52151f7136895
ダウンロード: https://www.linuxfromscratch.org/patches/lfs/11.2/systemd-251-glibc_2.36_fix-1.patch
MD5 sum: fd8dc901e73ad00dc72a351a0d4ac48c
ダウンロード: https://www.linuxfromscratch.org/patches/lfs/11.2/zstd-1.5.2-upstream_fixes-1.patch
MD5 sum: a7e576e3f87415fdf388392b257cdcf3
全パッチの合計サイズ: 約 189.4 KB
上に挙げた必須のパッチに加えて LFS コミュニティが提供する任意のパッチが数多くあります。 それらは微小な不備改修や、デフォルトでは利用できない機能を有効にするなどを行います。 https://www.linuxfromscratch.org/patches/downloads/ にて提供しているパッチ類を確認してください。 そして自分のシステムにとって必要なものは自由に適用してください。
本章では一時システムをビルドするために、あともう少し作業を行います。 $LFS
ディレクトリ内に、一連のインストールディレクトリを作ります。
リスク軽減のために一般ユーザーを生成し、このユーザーにおいてのビルド環境を作ります。 また LFS
パッケージ類の構築時間を測る手段として標準時間「SBUs」について説明し、各パッケージのテストスイートについて触れます。
LFS パーティションに対して行う最初の作業は、限定的なディレクトリ階層を作り出すことです。 第 6 章(また glibc や libstdc++ においては 第 5 章)においてビルドするプログラムを、最終的なディレクトリにインストールするためです。 第 8 章 にある一時的なプログラムを、再構築して上書きしていくために必要となります。
必要となるディレクトリレイアウトを生成するため、root
ユーザーになって以下を実行します。
mkdir -pv $LFS/{etc,var} $LFS/usr/{bin,lib,sbin} for i in bin lib sbin; do ln -sv usr/$i $LFS/$i done case $(uname -m) in x86_64) mkdir -pv $LFS/lib64 ;; esac
第 6 章 にあるプログラムはクロスコンパイラーによってビルドされます。 (詳しくは ツールチェーンの技術的情報 を参照してください。) クロスコンパイラーは他のプログラムとは切り分けるため、特別なディレクトリにインストールすることにします。 ここでそのディレクトリを生成します。
mkdir -pv $LFS/tools
root
ユーザーでログインしていると、ちょっとした誤操作がもとで、システムを破壊する重大な事態につながることがあります。
そこでパッケージのビルドにあたっては通常のユーザー権限にて作業することにします。
あなた自身のユーザーを利用するのでも構いませんが、全く新しいユーザー環境として lfs
というユーザーを作成するのが分かりやすいでしょう。 所属するグループも
lfs
という名で作成します。
ビルド作業においてはこのユーザーを利用していきます。 そこで root
ユーザーになって、新たなユーザーを追加する以下のコマンドを実行します。
groupadd lfs useradd -s /bin/bash -g lfs -m -k /dev/null lfs
コマンドラインオプションの意味
-s
/bin/bash
lfs
ユーザーが利用するデフォルトのシェルを
bash にします。
-g
lfs
lfs
ユーザーのグループを
lfs
とします。
-m
lfs
ユーザーのホームディレクトリを生成します。
-k
/dev/null
このパラメーターは、ディレクトリ名をヌルデバイス (null device) に指定しています。
こうすることでスケルトンディレクトリ (デフォルトは /etc/skel
) からのファイル群のコピーを無効とします。
lfs
生成するユーザーの名称を与えます。
lfs
ユーザーとしてログインするために
lfs
に対するパスワードを設定します。
(root
ユーザーでログインしている時に
lfs
へのユーザー切り替えを行なう場合には
lfs
ユーザーのパスワードは設定しておく必要はありません。)
passwd lfs
$LFS
ディレクトリの所有者を lfs
ユーザーとすることで、このディレクトリ配下の全ディレクトリへのフルアクセス権を設定します。
chown -v lfs $LFS/{usr{,/*},lib,var,etc,bin,sbin,tools} case $(uname -m) in x86_64) chown -v lfs $LFS/lib64 ;; esac
ホストシステムによっては、以下のコマンドを実行しても正常に処理されず、lfs
ユーザーへのログインがバックグラウンドで処理中のままとなってしまうことがあります。 プロンプトに "lfs:~$"
という表示がすぐに現れなかった場合は、fg コマンドを入力することで解決するかもしれません。
lfs
でログインします。
これはディスプレイマネージャーを通じて仮想端末を用いることができます。
また以下のユーザー変更コマンドを用いるのでも構いません。
su - lfs
パラメーター「-
」は su コマンドの実行において、非ログイン
(non-login) シェルではなく、ログインシェルを起動することを指示します。
ログインシェルとそうでないシェルの違いについては bash(1)
や info bash
を参照してください。
作業しやすい動作環境とするために bash
シェルに対するスタートアップファイルを二つ作成します。 lfs
ユーザーでログインして、以下のコマンドによって .bash_profile
ファイルを生成します。
cat > ~/.bash_profile << "EOF"
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
EOF
lfs
ユーザーとしてログインした時、起動されるシェルは普通はログインシェルとなります。 この時、ホストシステムの
/etc/profile
ファイル
(おそらく環境変数がいくつか定義されている) と .bash_profile
が読み込まれます。 .bash_profile
ファイル内の exec env -i.../bin/bash
というコマンドが、起動しているシェルを全くの空の環境として起動し直し HOME
、 TERM
、PS1
という環境変数だけを設定します。
これはホストシステム内の不要な設定や危険をはらんだ設定を、ビルド環境に持ち込まないようにするためです。
このようにすることできれいな環境作りを実現できます。
新しく起動するシェルはログインシェルではなくなります。 したがってこのシェルは /etc/profile
ファイルや .bash_profile
ファイルの内容を読み込んで実行することはなく、代わりに
.bashrc
ファイルを読み込んで実行します。
そこで以下のようにして .bashrc
ファイルを生成します。
cat > ~/.bashrc << "EOF"
set +h
umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
LFS_TGT=$(uname -m)-lfs-linux-gnu
PATH=/usr/bin
if [ ! -L /bin ]; then PATH=/bin:$PATH; fi
PATH=$LFS/tools/bin:$PATH
CONFIG_SITE=$LFS/usr/share/config.site
export LFS LC_ALL LFS_TGT PATH CONFIG_SITE
EOF
.bashrc
内の設定の意味
set
+h
set +h
コマンドは bash
のハッシュ機能を無効にします。 通常このハッシュ機能は有用なものです。
実行ファイルのフルパスをハッシュテーブルに記憶しておき、再度そのパスを探し出す際に PATH
変数の探査を省略します。
しかしこれより作り出すツール類はインストール直後にすぐ利用していきます。
ハッシュ機能を無効にすることで、プログラム実行が行われる際に、シェルは必ず PATH
を探しにいきます。 つまり $LFS/tools/bin
ディレクトリ以下に新たに構築したツール類は必ず実行されるようになるわけです。
そのツールの古いバージョンがホストディストリビューションのディレクトリ、/usr/bin
または /bin
にあったとしても、その場所を覚えていて実行されるということがなくなります。
umask
022
ユーザーのファイル生成マスク (file-creation mask; umask) を 022
にセットするのは、新たなファイルやディレクトリの生成はその所有者にのみ許可し、他者は読み取りと実行を可能とするためです。
(システムコール open(2)
にてデフォルトモードが適用される場合、新規生成ファイルのパーミッションモードは 644、同じくディレクトリは
755 となります。)
LFS=/mnt/lfs
環境変数 LFS
は常に指定したマウントポイントを指し示すように設定します。
LC_ALL=POSIX
LC_ALL
変数は特定のプログラムが扱う国情報を制御します。
そのプログラムが出力するメッセージを、指定された国情報に基づいて構成します。 LC_ALL
変数は「POSIX」か「C」にセットしてください。
(両者は同じです。) そのようにセットしておけば、chroot 環境下での作業が問題なく進められます。
LFS_TGT=(uname
-m)-lfs-linux-gnu
LFS_TGT
変数は標準にないマシン名称を設定します。
しかしこれはこの先、クロスコンパイラーやクロスリンカーの構築、これを用いたツールチェーンの構築の際に、うまく動作させるための設定です。
詳しくは ツールチェーンの技術的情報にて説明しているので参照してください。
PATH=/usr/bin
最近の Linux ディストリビューションでは /bin
と /usr/bin
をマージしているものが多くあります。
その場合、第 6 章
に対しての標準の PATH
変数は /usr/bin/
に設定するだけで十分です。 そうでない場合は、パスに対して
/bin
を加える必要があります。
if [ ! -L
/bin ]; then PATH=/bin:$PATH; fi
/bin
がシンボリックリンクではないは
PATH
変数に加える必要があります。
PATH=$LFS/tools/bin:$PATH
$LFS//tools/bin
ディレクトリを
PATH 変数の先頭に設定します。 第 5 章の冒頭においてインストールしたクロスコンパイラーは、インストールした直後からシェル上から実行できるようになります。
この設定を行うことで、ハッシュ機能をオフにしたことと連携して、ホスト上のコンパイラーが利用されないようにします。
CONFIG_SITE=$LFS/usr/share/config.site
第 5 章 と 第 6 章
においてこの変数を設定しておかないと、ディストリビューションによっては configure
スクリプトが、ホストシステム上の /usr/share/config.site
から設定項目を取得してしまうことがあります。 ホストの影響が及ばないようにここでオーバーライドします。
export
...
上のコマンド実行は、設定済の変数を改めて設定するものになりますが、シェルを新たに呼び出しても確実に設定されるようにエクスポートを行うことにします。
商用ディストリビューションの中には、bash
の初期化を行うスクリプトとして、ドキュメント化されていない /etc/bash.bashrc
というものを加えているものがあります。
このファイルは lfs
ユーザー環境を修正してしまう可能性があります。 それにより LFS
にとっての重要パッケージのビルドに支障をきたすことがあります。 lfs
ユーザー環境をきれいに保つため、/etc/bash.bashrc
というファイルが存在しているかどうかを確認してください。 そして存在していたらファイルを移動させてください。
root
ユーザーになって以下を実行します。
[ ! -e /etc/bash.bashrc ] || mv -v /etc/bash.bashrc /etc/bash.bashrc.NOUSE
第 7 章 の冒頭において
lfs
ユーザーの利用を終えたとき(必要であれば)/etc/bash.bashrc
を元に戻してください。
なお 「Bash-5.1.16」 においてビルドした、LFS における Bash
パッケージは、/etc/bash.bashrc
をロードしたり読み取ったりするように設定されていません。 したがって完璧な LFS
システムであれば、このファイルは不要なものです。
一時的なツールを構築する準備の最後として、今作り出したユーザープロファイルを source によって取り込みます。
source ~/.bash_profile
各パッケージをコンパイルしインストールするのにどれほどの時間を要するか、誰しも知りたくなるところです。 しかし Linux From Scratch は数多くのシステム上にて構築可能であるため、正確な処理時間を見積ることは困難です。 最も大きなパッケージ (Glibc) の場合、処理性能の高いシステムでも20分はかかります。 それが性能の低いシステムとなると3日はかかるかもしれません! 本書では処理時間を正確に示すのでなく、標準ビルド単位 (Standard Build Unit; SBU) を用いることにします。
SBU の測定は以下のようにします。 本書で最初にコンパイルするのは 第 5 章における binutils です。 このパッケージのコンパイルに要する時間を標準ビルド時間とし、他のコンパイル時間はその時間からの相対時間として表現します。
例えばあるパッケージのコンパイル時間が 4.5 SBU であったとします。 そして binutils の 1 回目のコンパイルが 10 分であったとすると、そのパッケージは およそ 45 分かかることを意味しています。 幸いにも、たいていのパッケージは binutils よりもコンパイル時間は短いものです。
一般にコンパイル時間は、例えばホストシステムの GCC のバージョンの違いなど、多くの要因に左右されるため SBU 値は正確なものになりません。 SBU 値は、インストールに要する時間の目安を示すものに過ぎず、場合によっては十数分の誤差が出ることもあります。
最新のシステムは複数プロセッサー (デュアルコアとも言います) であることが多く、パッケージのビルドにあたっては「同時並行のビルド」によりビルド時間を削減できます。 その場合プロセッサー数がいくつなのかを環境変数に指定するか、あるいは make プログラムの実行時に指定する方法があります。 例えば Intel i5-6500 CPU であれば、以下のようにして同時並行の 4 つのプロセスを実行することができます。
export MAKEFLAGS='-j4'
あるいはビルド時の指定として以下のようにすることもできます。
make -j4
上のようにして複数プロセッサーが利用されると、本書に示している SBU 単位は、通常の場合に比べて大きく変化します。 そればかりか場合により make 処理に失敗することもあります。 したがってビルド結果を検証するにしても話が複雑になります。 複数のプロセスラインがインターリーブにより多重化されるためです。 ビルド時に何らかの問題が発生したら、単一プロセッサー処理を行ってエラーメッセージを分析してください。
各パッケージにはたいていテストスイートがあります。 新たに構築したパッケージに対してはテストスイートを実行しておくのがよいでしょう。 テストスイートは「健全性検査 (sanity check)」を行い、パッケージのコンパイルが正しく行われたことを確認します。 テストスイートの実行によりいくつかのチェックが行われ、開発者の意図したとおりにパッケージが正しく動作することを確認していきます。 ただこれは、パッケージにバグがないことを保証するものではありません。
テストスイートの中には他のものにも増して重要なものがあります。 例えば、ツールチェーンの要である GCC、binutils、glibc に対してのテストスイートです。 これらのパッケージはシステム機能を確実なものとする重要な役割を担うものであるためです。 GCC と glibc におけるテストスイートはかなりの時間を要します。 それが低い性能のマシンであればなおさらです。 でもそれらを実行しておくことを強く推奨します。
第 5 章 と 第 6 章 においてテストスイートを実行することはできません。 各プログラムはクロスコンパイラーによってコンパイルされているので、ビルドしているホスト上での実行が対応できないためです。
binutils と GCC におけるテストスイートの実行では、擬似端末 (pseudo terminals; PTY)
を使い尽くす問題が発生します。 これにより相当数のテストが失敗します。
これが発生する理由はいくつかありますが、もっともありがちな理由としてはホストシステムの devpts
ファイルシステムが正しく構成されていないことがあげられます。
この点については https://www.linuxfromscratch.org/lfs/faq.html#no-ptys
においてかなり詳しく説明しています。
パッケージの中にはテストスイートに失敗するものがあります。 しかしこれらは開発元が認識しているもので致命的なものではありません。 以下の https://www.linuxfromscratch.org/lfs/build-logs/11.2/ に示すログを参照して、失敗したテストが実は予期されているものであるかどうかを確認してください。 このサイトは本書におけるすべてのテストスイートの正常な処理結果を示すものです。
この部は 3 つのステージに分かれています。 1 つめはクロスコンパイラーと関連ライブラリをビルドします。 2 つめはそのクロスコンパイラーを使って、ホストのパッケージからは切り離された形で、各種ユーティリティーをビルドします。 そして 3 つめでは chroot 環境に入ることで、さらにホスト環境から離れて、最終システムをビルドするために必要となる残りのツール類をビルドします。
この部から、新システムのビルドに向けた本格的作業を開始します。 ここではより注意深く、本書が示す手順どおりに作業を進めていくことが必要です。 そこで何を行っているのかを十分に理解するようにしてください。 これはビルドを完成させたいという思いとは別の話です。 ただ単に書かれている内容を入力するだけの作業はやめてください。 わかっていないことがあれば、しっかりと本書を読むようにしてください。 また入力した内容やコマンドの処理結果は、ファイル出力を行うなどして記録するようにしてください。 tee ユーティリティーを使うことにすれば、何かおかしなことになっても調べられるようになります。
次の節では、ビルド過程における技術的な情報を示します。 それに続く節では、極めて重要な 全般的なコンパイル手順を示しています。
本節ではシステムをビルドする原理や技術的な詳細について説明します。 この節のすべてをすぐに理解する必要はありません。 この先、実際の作業を行っていけば、いろいろな情報が明らかになってくるはずです。 各作業を進めながら、いつでもこの節に戻って読み直してみてください。
第 5 章 と 第 6 章 の最終目標は一時的なシステム環境を構築することです。 この一時的なシステムはシステム構築のための十分なツール類を有していて、ホストシステムとは切り離されたものです。 この環境へは chroot によって移行します。この環境は 第 8 章 において、クリーンでトラブルのない LFS システムの構築を行う土台となるものです。 構築手順の説明においては、初心者の方であっても失敗を最小限にとどめ、同時に最大限の学習材料となるように心がけています。
ビルド過程は クロスコンパイル を基本として行います。 通常クロスコンパイルとは、ビルドを行うマシンとは異なるマシン向けにコンパイラーや関連ツールチェーンをビルドすることです。 これは厳密には LFS に必要なものではありません。 というのも新たに作り出すシステムは、ビルドに使ったマシンと同一環境で動かすことにしているためです。 しかしクロスコンパイルには大きな利点があって、クロスコンパイルによってビルドしたものは、ホスト環境上にはまったく依存できないものとなります。
LFS はクロスツールチェーン(あるいはネイティブツールチェーン)のビルドを説明する書ではなく、その説明は行っていません。 クロスツールチェーンは、LFS のビルドとは異なる別の目的で用いるものであるため、何を行っているのかが十分に分かっていないまま、クロスチェーン向けのコマンドを利用することは避けてください。
クロスコンパイルには必要な捉え方があって、それだけで 1 つの節を当てて説明するだけの価値があるものです。 初めて読む方は、この節を読み飛ばしてかまいません。 ただしビルド過程を十分に理解するためには、後々この節に戻ってきて読んで頂くことをお勧めします。
ここにおいて取り上げる用語を定義しておきます。
ビルド作業を行うマシンのこと。 他の節においてこのマシンは "ホスト(host)" と呼ぶこともあります。
ビルドされたプログラムを実行するマシンまたはシステムのこと。 ここでいう "ホスト" とは、他の節でいうものと同一ではありません。
コンパイラーにおいてのみ用いられます。 コンパイラーの生成コードを必要とするマシンのこと。 これはビルドやホストとは異なることもあります。
例として以下のシナリオを考えてみます。 (これはよく "カナディアンクロス(Canadian Cross)" とも呼ばれるものです。) コンパイラーが低速なマシン上にだけあるとします。 これをマシン A と呼び、コンパイラーは ccA とします。 これとは別に高速なマシン(マシン B)があって、ただしそこにはコンパイラーがありません。 そしてここから作り出すプログラムコードは、まったく別の低速マシン(マシン C)向けであるとします。 マシン C 向けにコンパイラーをビルドするためには、以下の 3 つの段階を経ることになります。
段階 | ビルド | ホスト | ターゲット | 作業 |
---|---|---|---|---|
1 | A | A | B | マシン A 上の ccA を使い、クロスコンパイラー cc1 をビルド。 |
2 | A | B | C | マシン A 上の cc1 を使い、クロスコンパイラー cc2 をビルド。 |
3 | B | C | C | マシン B 上の cc2 を使い、コンパイラー ccC をビルド。 |
マシン C 上で必要となる他のプログラムは、高速なマシン B 上において cc2 を用いてコンパイルすることができます。 マシン B がマシン C 向けのプログラムを実行できなかったとすると、マシン C そのものが動作するようにならない限り、プログラムのビルドやテストは一切できないことになります。 たとえば ccC をテストするには、以下の 4 つめの段階が必要になります。
段階 | ビルド | ホスト | ターゲット | 作業 |
---|---|---|---|---|
4 | C | C | C | マシン C 上にて ccC を使い ccC そのものの再ビルドとテストを実施。 |
上の例において cc1 と cc2 だけがクロスコンパイラーです。 つまりこのコンパイラーは、これを実行しているマシンとは別のマシンに対するコードを生成できるものです。 これに比べて ccA と ccC というコンパイラーは、実行しているマシンと同一マシン向けのコードしか生成できません。 そういうコンパイラーのこをネイティブ コンパイラーと呼びます。
ほぼすべてのビルドシステムにおいては、cpu-vendor-kernel-os
という形式のマシントリプレット(triplet)と呼ばれる名称が用いられます。 お気づきのことと思いますが、なぜ
"トリプレット" といいながら 4 つの項目からなる名前なのでしょう。 その理由はこれまでの経緯にあります。 当初は
3 つの項目による名前を使っていれば、マシンを間違いなく特定できるものでした。
しかし新たなマシン、新たなシステムが登場するようになって、これでは不十分であることがわかりました。 "トリプレット"
という語だけが残ったわけです。 マシンのトリプレットを確認する一番簡単な方法は、config.guess
スクリプトを実行することです。 これは多くのパッケージのソースに含まれています。 binutils
のソースを伸張(解凍)し、この ./config.guess
スクリプトを実行して、その出力を確認してください。 たとえば 32
ビットのインテルプロセッサーであれば、i686-pc-linux-gnu と出力されます。 64
ビットシステムであれば x86_64-pc-linux-gnu となります。
またプラットフォームのダイナミックリンカーの名前にも注意してください。 これはダイナミックローダーとも呼ばれます。
(binutils の一部である標準リンカー ld とは別ものですから混同しないでください。)
ダイナミックリンカーは Glibc
によって提供されているもので、何かのプログラムが必要とする共有ライブラリを検索しロードします。
そして実行できるような準備を行って、実際に実行します。 32 ビットインテルマシンに対するダイナミックリンカーの名前は
ld-linux.so.2
となります。 (64
ビットシステムであれば ld-linux-x86-64.so.2
となります。)
ダイナミックリンカーの名前を確実に決定するには、何でもよいのでホスト上の実行モジュールを調べます。
readelf -l <name of
binary> | grep interpreter
というコマンドを実行することです。 出力結果を見てください。
どのようなプラットフォームであっても確実な方法は、shlib-versions
というファイルを見てみることです。 これは
Glibc ソースツリーのルートに存在しています。
LFS ではクロスコンパイルに似せた作業を行うため、ホストのトリプレットを多少調整します。 LFS_TGT
変数において "vendor" 項目を変更します。
またクロスリンカーやクロスコンパイラーを生成する際には --with-sysroot
オプションを利用します。
これはホスト内に必要となるファイルがどこにあるかを指示するものです。 第 6 章
においてビルドされる他のプログラムが、ビルドマシンのライブラリにリンクできないようにするためです。 以下の 2
段階は必須ですが、最後の 1 つはテスト用です。
段階 | ビルド | ホスト | ターゲット | 作業 |
---|---|---|---|---|
1 | pc | pc | lfs | pc 上の cc-pc を使い、クロスコンパイラー cc1 をビルド。 |
2 | pc | lfs | lfs | pc 上の cc1 を使い、クロスコンパイラー cc-lfs をビルド。 |
3 | lfs | lfs | lfs | lfs 上の cc-lfs を使い cc-lfs そのものの再ビルドとテストを実施。 |
上の表において "pc 上の" というのは、すでにそのディストリビューションにおいてインストールされているコマンドを実行することを意味します。 また "lfs 上の" とは、chroot 環境下にてコマンドを実行することを意味します。
さてクロスコンパイルに関しては、まだまだあります。 C 言語というと単にコンパイラーがあるだけではなく、標準ライブラリも定義しています。 本書では glibc と呼ぶ GNU C ライブラリを用いています。 このライブラリは lfs マシン向けにコンパイルされたものでなければなりません。 つまりクロスコンパイラー cc1 を使うということです。 しかしコンパイラーには内部ライブラリというものがあって、アセンブラー命令セットだけでは利用できない複雑な命令が含まれます。 その内部ライブラリは libgcc と呼ばれ、完全に機能させるには glibc ライブラリにリンクさせなければなりません。 さらに C++ (libstdc++) に対する標準ライブラリも、glibc にリンクさせる必要があります。 このようなニワトリと卵の問題を解決するには、まず libgcc に基づいた低機能版の cc1 をビルドします。 この cc1 にはスレッド処理や例外処理といった機能が含まれていません。 その後に、この低機能なコンパイラーを使って glibc をビルドします。 (glibc 自体は低機能ではありません。) そして libstdc++ をビルドします。 libstdc++ もやはり、libgcc と同じく機能がいくつか欠如しています。
これで話が終わるわけではありません。 上の段落における結論は以下のようになります。 cc1 からは完全な libstdc++ はビルドできないということです。 しかし第 2 段階においては、C/C++ ライブラリをビルドできる唯一のコンパイラーです。 もちろん第 2 段階においてビルドされるコンパイラー cc-lfs は、それらライブラリをビルドできます。 しかし (1) GCC ビルドシステムは、それが pc 上で利用できるかどうかわかりません、そして (2) pc 上にてそれを使うと pc 内のライブラリにリンクしてしまうリスクがあります。 なぜなら cc-lfs はネイティブコンパイラーであるからです。 そこで libstdc++ は、後々 chroot 環境内でビルドしなければならないのです。
クロスコンパイラーは、他から切り離された $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 を実行すると、検索するライブラリのパスとその検索順を示してくれます。
ダミープログラムをコンパイルして ld に --verbose
オプションをつけてリンクを行うと、どのファイルがリンクされたが分かります。 例えば $LFS_TGT-gcc dummy.c -Wl,--verbose
2>&1 | grep succeeded
と実行すれば、リンカーの処理中にオープンに成功したファイルがすべて表示されます。
次にインストールするのは 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
を実行します。
さらに詳細な情報を知りたいときは、ダミープログラムをコンパイルする際に -v
オプションをつけて実行します。 例えば
gcc -v dummy.c
と入力すると、プリプロセッサー、コンパイル、アセンブルの各処理工程が示されますが、さらに gcc
がインクルードした検索パスとその読み込み順も示されます。
次に健全化された (sanitized) Linux API ヘッダーをインストールします。 これにより、標準 C ライブラリ (Glibc) が Linux カーネルが提供する機能とのインターフェースを可能とします。
次のパッケージは Glibc です。 Glibc
構築の際に気にかけるべき重要なものは、コンパイラー、バイナリツール、カーネルヘッダーです。
コンパイラーについては、一般にはあまり問題にはなりません。 Glibc は常に configure
スクリプトにて指定される --host
パラメーターに関連づけしたコンパイラーを用いるからです。 我々の作業においてそのコンパイラーとは $LFS_TGT-gcc になります。
バイナリツールとカーネルヘッダーは多少複雑です。 従って無理なことはせずに有効な configure
オプションを選択することが必要です。 configure 実行の後は
build
ディレクトリにある config.make
ファイルに重要な情報が示されているので確認してみてください。
なお CC="$LFS_TGT-gcc"
とすれば、($LFS_TGT
が展開されて)どこにある実行モジュールを利用するかを制御でき -nostdinc
と -isystem
を指定すれば、コンパイラーに対してインクルードファイルの検索パスを制御できます。 これらの指定は Glibc
パッケージの重要な面を示しています。 Glibc
がビルドされるメカニズムは自己完結したビルドが行われるものであり、ツールチェーンのデフォルト設定には基本的に依存しないことを示しています。
すでに述べたように、標準 C++ ライブラリはこの後でコンパイルします。 そして 第 6 章
では、プログラムそれ自身を必要としているプログラムをすべてビルドしていきます。
そのようなパッケージのインストール手順においては DESTDIR
変数を使い、LFS ファイルシステム内にインストールします。
第 6 章 の最後には、LFS
のネイティブコンパイラーをインストールします。 はじめに DESTDIR
を使って binutils 2
回めをビルドし、他のプログラムにおいてもおなじようにインストールを行います。 2 回めとなる GCC
ビルドでは、libstdc++ や不必要なライブラリは省略します。 GCC の configure
スクリプトにはハードコーディングされている部分があるので、CC_FOR_TARGET
はホストのターゲットが同じであれば cc になります。
しかしビルドシステムにおいては異なります。 そこで configure オプションには CC_FOR_TARGET=$LFS_TGT-gcc
を明示的に指定するようにしています。
第 7 章での chroot による環境下では、最初の作業は libstdc++ をビルドすることです。 そして各種プログラムのインストールを、ツールチェーンを適切に操作しながら実施していきます。 これ以降、コアとなるツールチェーンは自己完結していきます。 そしてシステムの全機能を動作させるための全パッケージの最終バージョンを、ビルドしテストしインストールします。
パッケージをビルドしていく際には、以下に示す内容を前提とします:
パッケージの中には、コンパイルする前にパッチを当てるものがあります。 パッチを当てるのは、そのパッケージが抱える問題を回避するためです。 本章と後続の章でパッチを当てるものがあり、あるいは本章と後続の章のいずれか一方でパッチを当てるものもあります。 したがってパッチをダウンロードする説明が書かれていないなら、何も気にせず先に進んでください。 パッチを当てた際に offset や fuzz といった警告メッセージが出る場合がありますが、これらは気にしないでください。 このような時でもパッチは問題なく適用されています。
コンパイルの最中に、警告メッセージが画面上に出力されることがよくあります。 これは問題はないため無視して構いません。 警告メッセージは、メッセージ内に説明されているように、C や C++ の文法が誤りではないものの推奨されていないものであることを示しています。 C 言語の標準はよく変更されますが、パッケージの中には古い基準に従っているものもあります。 問題はないのですが、警告として画面表示されることになるわけです。
もう一度、環境変数 LFS
が正しく設定されているかを確認します。
echo $LFS
上の出力結果が LFS パーティションのマウントポイントのディレクトリであることを確認してください。 本書では
/mnt/lfs
ディレクトリとして説明しています。
最後に以下の二つの点にも注意してください。
ビルドにあたっては ホストシステム要件にて示す要件やシンボリックリンクが、正しくインストールされていることを前提とします。
bash シェルの利用を想定しています。
sh は bash へのシンボリックリンクであるものとします。
/usr/bin/awk は gawk へのシンボリックリンクであるものとします。
/usr/bin/yacc は bison へのシンボリックリンクであるか、あるいは bison を実行するためのスクリプトであるものとします。
ビルド作業では以下の点が重要です。
ソースやパッチファイルを配置するディレクトリは /mnt/lfs/sources/ などのように chroot 環境でもアクセスが出来るディレクトリとしてください。
ソースディレクトリに入ります。
tar コマンドを使ってパッケージの tarball を伸張(解凍)します。 第 5 章 と 第 6 章 では、パッケージを伸張(解凍)するのは lfs ユーザーとします。
パッケージ tarball はどこか別ディレクトリにあってもかまいませんが、ソースツリーをどこか別の場所でビルドする方法についてはサポートしていません。 特にどこか別に配置しているソースコードを cp -R を使ってコピーすると、ソースツリー内のリンクやタイムスタンプを壊しかねません。 そうなるとビルドの失敗に通じることになります。
パッケージの伸張 (解凍) 後に生成されたディレクトリに入ります。
本書の手順に従ってビルド作業を行っていきます。
ソースディレクトリに戻ります。
ビルド作業を通じて生成されたパッケージディレクトリを削除します。
本章ではクロスコンパイラーと関連ツールのビルド方法を示します。 ここでのクロスコンパイルは見せかけですが、その原理は本当のクロスツールチェーンと同じです。
本章にてビルドされるプログラムは $LFS/tools
ディレクトリにインストールされます。 これはそれ以降にインストールされるファイルとは区別されます。
一方でライブラリについては、ビルドしたいシステムに適合するように最終的な場所にインストールします。
Binutils パッケージは、リンカーやアセンブラーなどのようにオブジェクトファイルを取り扱うツール類を提供します。
全般的なコンパイル手順 と書かれた節に戻って再度説明をよく読み、重要事項として説明している内容をよく理解しておいてください。 そうすればこの後の無用なトラブルを減らすことができるはずです。
Binutils は一番最初にビルドするパッケージです。 ここでビルドされるリンカーやアセンブラーを使って、Glibc や GCC のさまざまな機能が利用できるかどうかを判別することになります。
Binutils のドキュメントでは Binutils をビルドする際に、ビルド専用のディレクトリを使ってビルドすることを推奨しています。
mkdir -v build cd build
本節以降で SBU値を示していきます。 これを活用していくなら、本パッケージの configure
から初めのインストールまでの処理時間を計測しましょう。 具体的には処理コマンドを time で囲んで time { ../configure ... && make
&& make install; }
と入力すれば実現できます。
Binutils をコンパイルするための準備をします。:
../configure --prefix=$LFS/tools \ --with-sysroot=$LFS \ --target=$LFS_TGT \ --disable-nls \ --enable-gprofng=no \ --disable-werror
configure オプションの意味
--prefix=$LFS/tools
configure スクリプトに対して binutils プログラムを $LFS/tools
ディレクトリ以下にインストールすることを指示します。
--with-sysroot=$LFS
クロスコンパイル時に、ターゲットとして必要となるシステムライブラリを $LFS より探し出すことを指示します。
--target=$LFS_TGT
変数 LFS_TGT
に設定しているマシン名は
config.guess
スクリプトが返すものとは微妙に異なります。 そこでこのオプションは、binutils
のビルドにあたってクロスリンカーをビルドするように configure
スクリプトに指示するものです。
--disable-nls
一時的なツール構築にあたっては i18n 国際化は行わないことを指示します。
--enable-gprofng=no
これは gprofng のビルドを無効にします。 gprofng は一時的ツールにおいては不要であるからです。
--disable-werror
ホストのコンパイラーが警告を発した場合に、ビルドが中断することがないようにします。
パッケージをコンパイルします。
make
パッケージをインストールします。
make install
本パッケージの詳細は 「Binutils の構成」を参照してください。
GCC パッケージは C コンパイラーや C++ コンパイラーなどの GNU コンパイラーコレクションを提供します。
GCC は GMP、MPFR、MPC の各パッケージを必要とします。 これらのパッケージはホストシステムに含まれていないかもしれないため、以下を実行してビルドの準備をします。 個々のパッケージを GCC ソースディレクトリの中に伸張 (解凍) し、ディレクトリ名を変更します。 これは GCC のビルド処理においてそれらを自動的に利用できるようにするためです。
本節においては誤解が多く発生しています。 ここでの手順は他のものと同様であり、手順の概要 (パッケージビルド手順) は説明済です。 まず初めに gcc の tarball を伸張 (解凍) し、生成されたソースディレクトリに移動します。 それに加えて本節では、以下の手順を行うものとなります。
tar -xf ../mpfr-4.1.0.tar.xz mv -v mpfr-4.1.0 mpfr tar -xf ../gmp-6.2.1.tar.xz mv -v gmp-6.2.1 gmp tar -xf ../mpc-1.2.1.tar.gz mv -v mpc-1.2.1 mpc
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 のドキュメントでは、専用のビルドディレクトリを作成することが推奨されています。
mkdir -v build cd build
GCC をコンパイルするための準備をします。
../configure \ --target=$LFS_TGT \ --prefix=$LFS/tools \ --with-glibc-version=2.36 \ --with-sysroot=$LFS \ --with-newlib \ --without-headers \ --disable-nls \ --disable-shared \ --disable-multilib \ --disable-decimal-float \ --disable-threads \ --disable-libatomic \ --disable-libgomp \ --disable-libquadmath \ --disable-libssp \ --disable-libvtv \ --disable-libstdcxx \ --enable-languages=c,c++
configure オプションの意味
--with-glibc-version=2.36
このオプションは、ターゲットにおいて用いられることになる glibc のバージョンを指定します。 これはホストディストリビューションにある libc のバージョンとは関係がありません。 1 回めの gcc によってコンパイルされるものは、すべて chroot 環境内で実行されるものであって、ホストにある libc とは切り離されているためです。
--with-newlib
この時点では利用可能な C ライブラリがまだ存在しません。 したがって libgcc のビルド時に inhibit_libc 定数を定義します。 これを行うことで、libc サポートを必要とするコード部分をコンパイルしないようにします。
--without-headers
完璧なクロスコンパイラーを構築するなら、GCC はターゲットシステムに互換性を持つ標準ヘッダーを必要とします。 本手順においては標準ヘッダーは必要ありません。 このスイッチは GCC がそういったヘッダーを探しにいかないようにします。
--disable-shared
このスイッチは内部ライブラリをスタティックライブラリとしてリンクすることを指示します。 共有ライブラリが glibc を必要としており、処理しているシステム上にはまだインストールされていないためです。
--disable-multilib
x86_64 に対して LFS は multilib のサポートをしていません。 このオプション指定は x86 には無関係です。
--disable-decimal-float,
--disable-threads, --disable-libatomic,
--disable-libgomp, --disable-libquadmath,
--disable-libssp, --disable-libvtv,
--disable-libstdcxx
これらのオプションは順に、十進浮動小数点制御、スレッド処理、libatomic, libgomp, libquadmath, libssp, libvtv, C++ 標準ライブラリのサポートをいずれも無効にすることを指示します。 これらの機能を含めていると、クロスコンパイラーをビルドする際にはコンパイルに失敗します。 またクロスコンパイルによって一時的な libc ライブラリを構築する際には不要なものです。
--enable-languages=c,c++
このオプションは C コンパイラーおよび C++ コンパイラーのみビルドすることを指示します。 この時点で必要なのはこの言語だけだからです。
GCC をコンパイルします。
make
パッケージをインストールします。
make install
ここでの GCC ビルドにおいては、内部にあるシステムヘッダーファイルをいくつかインストールしました。 そのうちの
limits.h
というものは、対応するシステムヘッダーファイルである limits.h
を読み込むものになっています。 そのファイルはここでは
$LFS/usr/include/limits.h
になります。 ただし GCC をビルドしたこの時点において $LFS/usr/include/limits.h
は存在していません。
したがってインストールされたばかりの内部ヘッダーファイルは、部分的に自己完結したファイルとなり、システムヘッダーファイルによる拡張された機能を含むものになっていません。
glibc をビルドする際にはこれでもかまわないのですが、後々内部ヘッダーファイルは完全なものが必要になります。
以下のようなコマンドを通じて、その内部ヘッダーファイルの完成版を作り出します。 このコマンドは GCC
ビルドが通常行っている方法と同じものです。
cd .. cat gcc/limitx.h gcc/glimits.h gcc/limity.h > \ `dirname $($LFS_TGT-gcc -print-libgcc-file-name)`/install-tools/include/limits.h
本パッケージの詳細は 「GCC の構成」を参照してください。
Linux API ヘッダー(linux-5.19.2.tar.xz 内) は glibc が利用するカーネル API を提供します。
Linux カーネルはアプリケーションプログラミングインターフェース (Application Programming Interface) を、システムの C ライブラリ (LFS の場合 Glibc) に対して提供する必要があります。 これを行うには Linux カーネルのソースに含まれる、さまざまな C ヘッダーファイルを「健全化 (sanitizing)」して利用します。
本パッケージ内にある不適切なファイルを残さないように、以下を処理します。
make mrproper
そしてユーザーが利用するカーネルヘッダーファイルをソースから抽出します。 推奨されている make
ターゲット「headers_install」は利用できません。 なぜなら
rsync
が必要となり、この時点では利用できないからです。 ヘッダーファイルは初めに ./usr
にコピーし、その後に必要な場所にコピーされます。
make headers find usr/include -type f ! -name '*.h' -delete cp -rv usr/include $LFS/usr
Glibc パッケージは主要な C ライブラリを提供します。 このライブラリは基本的な処理ルーチンを含むもので、メモリ割り当て、ディレクトリ走査、ファイルのオープン、クローズや入出力、文字列操作、パターンマッチング、算術処理、等々があります。
はじめに 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
上記のコマンドに間違いはありません。 ln
コマンドにはいくつか文法の異なるバージョンがあります。 間違いがあると思った場合には info coreutils ln や
ln(1)
をよく確認してください。
Glibc のプログラムの中で、FHS コンプライアンスに適合しない /var/db
ディレクトリを用いているものがあり、そこに実行時データを保存しています。
以下のパッチを適用することで、実行時データの保存ディレクトリを FHS に合致するものとします。
patch -Np1 -i ../glibc-2.36-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=3.2 \ --with-headers=$LFS/usr/include \ libc_cv_slibdir=/usr/lib
configure オプションの意味
--host=$LFS_TGT,
--build=$(../scripts/config.guess)
このようなオプションを組み合わせることで /tools
ディレクトリにあるクロスコンパイラー、クロスリンカーを使って
Glibc がクロスコンパイルされるようになります。
--enable-kernel=3.2
Linux カーネル 3.2 以上のサポートを行うよう指示します。 これ以前のカーネルは利用することができません。
--with-headers=$LFS/usr/include
これまでに $LFS/usr/include ディレクトリにインストールしたヘッダーファイルを用いて Glibc をビルドすることを指示します。 こうすればカーネルにどのような機能があるか、どのようにして処理効率化を図れるかなどの情報を Glibc が得られることになります。
libc_cv_slibdir=/usr/lib
この指定は 64 ビットマシンにおいて、ライブラリのインストール先をデフォルトの /lib64 ではなく /usr/lib とします。
ビルド中には以下のようなメッセージが出力されるかもしれません。
configure: WARNING: *** These auxiliary programs are missing or *** incompatible versions: msgfmt *** some features will be disabled. *** Check the INSTALL file for required versions.
msgfmt プログラムがない場合 (missing) や互換性がない場合 (incompatible) でも特に問題はありません。 msgfmt プログラムは Gettext パッケージが提供するもので、ホストシステムに含まれているかもしれません。
本パッケージは "並行ビルド (parallel make)" を行うとビルドに失敗するとの報告例があります。 もしビルドに失敗した場合は make コマンドに "-j1" オプションをつけて再ビルドしてください。
パッケージをコンパイルします。
make
パッケージをインストールします。
LFS
が適切に設定されていない状態で、推奨する方法とは異なり
root
によってビルドを行うと、次のコマンドはビルドした glibc をホストシステムにインストールしてしまいます。
これを行ってしまうと、ほぼ間違いなくホストが利用不能になります。
したがってその環境変数が適切に設定されていることを確認してから、以下のコマンドを実行してください。
make DESTDIR=$LFS install
make install オプションの意味
DESTDIR=$LFS
make 変数 DESTDIR
はほとんどすべてのパッケージにおいて、そのパッケージをインストールするディレクトリを定義するために利用されています。
これが設定されていない場合のデフォルトは、ルートディレクトリ(/
)となります。 ここではパッケージのインストール先を
$LFS
とします。 これは 「Chroot 環境への移行」
に入ってからはルートディレクトリとなります。
ldd スクリプト内にある実行可能なローダーへのパスがハードコーディングされているので、これを修正します。
sed '/RTLDLIST=/s@/usr@@g' -i $LFS/usr/bin/ldd
この時点で以下を必ず実施します。 新しいツールチェーンの基本的な機能 (コンパイルやリンク) が正常に処理されるかどうかを確認することです。 健全性のチェック (sanity check) を行うものであり、以下のコマンドを実行します。
echo 'int main(){}' | gcc -xc - readelf -l a.out | grep ld-linux
すべてが正常に処理され、エラーが発生しなければ、最終のコマンドの実行結果として以下が出力されるはずです。
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
インタープリター名は 32 ビットマシンの場合 /lib/ld-linux.so.2
となります。
出力結果が上とは異なったり、あるいは何も出力されなかったりした場合は、どこかに不備があります。 どこに問題があるのか調査、再試行を行って解消してください。 解決せずにこの先に進まないでください。
すべてが完了したら、テストファイルを削除します。
rm -v a.out
次節にてビルドするパッケージでは、ツールチェーンが正しく構築できたかどうかを再度チェックすることになります。 特に binutils 2 回めや gcc 2 回めのビルドに失敗したら、それ以前にインストールしてきた binutils, GCC, glibc のいずれかにてビルドがうまくできていないことを意味します。
ここでクロスツールチェーンが完成しました。 そこで limits.h のインストールを確定させます。 これには GCC 開発者が提供するユーティリティーを実行します。
$LFS/tools/libexec/gcc/$LFS_TGT/12.2.0/install-tools/mkheaders
本パッケージの詳細は 「Glibc の構成」を参照してください。
Libstdc++ は標準 C++ ライブラリです。 (GCC の一部が C++ によって書かれているため)C++ をコンパイルするために必要となります。 ただし gcc 1 回め をビルドするにあたっては、このライブラリのインストールを個別に行わなければなりません。 それはこのライブラリが glibc に依存していて、対象ディレクトリ内ではまだ glibc が利用できない状態にあるからです。
libstdc++ のソースは GCC
に含まれます。 したがってまずは GCC の tarball を伸張 (解凍) した上で gcc-12.2.0
ディレクトリに入って作業を進めます。
libstdc++ のためのディレクトリを新たに生成して移動します。
mkdir -v build cd build
libstdc++ をコンパイルするための準備をします。
../libstdc++-v3/configure \ --host=$LFS_TGT \ --build=$(../config.guess) \ --prefix=/usr \ --disable-multilib \ --disable-nls \ --disable-libstdcxx-pch \ --with-gxx-include-dir=/tools/$LFS_TGT/include/c++/12.2.0
configure オプションの意味
--host=...
利用するクロスコンパイラーを指示するものであり、/usr/bin
にあるものではなく、まさに先ほど作り出したものを指定するものです。
--disable-libstdcxx-pch
本スイッチは、既にコンパイルされたインクルードファイルをインストールしないようにします。 これはこの時点では必要ないためです。
--with-gxx-include-dir=/tools/$LFS_TGT/include/c++/12.2.0
インクルードファイルをインストールするディレクトリを指定します。 libstdc++ は LFS における標準
C++ ライブラリであるため、そのディレクトリは C++ コンパイラー ($LFS_TGT-g++) が標準 C++
インクルードファイルを探し出すディレクトリでなければなりません。
通常のビルドにおいてそのディレクトリ情報は、最上位ディレクトリの configure
のオプションにて指定します。 ここでの作業では、上のようにして明示的に指定します。 C++ コンパイラーは
sysroot パスに $LFS
(GCC 1
回めのビルド時に指定)をインクルードファイルの検索パスに加えます。 したがって実際には
$LFS/tools/$LFS_TGT/include/c++/12.2.0
となります。 DESTDIR
変数(以下の make
install
にて指定)とこのスイッチを組み合わせることで、ヘッダーファイルをそのディレクトリにインストールするようにします。
libstdc++ をコンパイルします。
make
ライブラリをインストールします。
make DESTDIR=$LFS install
クロスコンパイルにとっては libtool アーカイブファイルが邪魔になるため削除します。
rm -v $LFS/usr/lib/lib{stdc++,stdc++fs,supc++}.la
本パッケージの詳細は 「GCC の構成」を参照してください。
本章では、つい先ほど作り出したクロスツールチェーンを利用して、基本ユーティリティーをクロスコンパイルする方法を示します。 このユーティリティーは最終的な場所にインストールされますが、まだ利用することはできません。 基本的な処理タスクは、まだホストのツールに依存します。 ただしインストールされたライブラリは、リンクの際に利用されます。
ユーティリティーの利用は次の章において、「chroot」環境に入ってから可能になります。 ただしそこに至る前の章の中で、パッケージをすべて作り出しておく必要があります。 したがってホストシステムからは、まだ独立している状態ではありません。
ここでもう一度確認しておきますが、root
ユーザーとしてビルドを行う際にも LFS
の適切な設定が必要です。
それができていないと、コンピューターが利用できなくなる可能性があります。 本章は全体にわたって、lfs
ユーザーにより操作します。 環境は 「環境設定」
に示したものとなっている必要があります。
M4 パッケージはマクロプロセッサーを提供します。
M4 をコンパイルするための準備をします。
./configure --prefix=/usr \ --host=$LFS_TGT \ --build=$(build-aux/config.guess)
パッケージをコンパイルします。
make
パッケージをインストールします。
make DESTDIR=$LFS install
本パッケージの詳細は 「M4 の構成」を参照してください。
Ncurses パッケージは、端末に依存しない、文字ベースのスクリーン制御を行うライブラリを提供します。
ビルドにあたって gawk が必ず最初に見つかるようにします。
sed -i s/mawk// configure
そして以下のコマンドを実行して、ビルドホスト上に「tic」プログラムをビルドします。
mkdir build pushd build ../configure make -C include make -C progs tic popd
Ncurses をコンパイルするための準備をします。
./configure --prefix=/usr \ --host=$LFS_TGT \ --build=$(./config.guess) \ --mandir=/usr/share/man \ --with-manpage-format=normal \ --with-shared \ --without-normal \ --with-cxx-shared \ --without-debug \ --without-ada \ --disable-stripping \ --enable-widec
configure オプションの意味
--with-manpage-format=normal
本パラメーターは Ncurses が圧縮された man ページをインストールしないようにします。 ホストディストリビューションそのものが圧縮 man ページを利用していると、同じようになってしまうからです。
--with-shared
これは Ncurses において共有 C ライブラリをビルドしインストールします。
--without-normal
これは Ncurses においてスタティックな C ライブラリのビルドおよびインストールを行わないようにします。
--without-debug
これは Ncurses においてデバッグライブラリのビルドおよびインストールを行わないようにします。
--with-cxx-shared
これは Ncurses において共有 C++ バインディングをビルドしインストールします。 同時にスタティックな C++ バインディングのビルドおよびインストールは行わないようにします。
--without-ada
このオプションは Ncurses に対して Ada コンパイラーのサポート機能をビルドしないよう指示します。 この機能はホストシステムでは提供されているかもしれませんが、chroot 環境に入ってしまうと利用できなくなります。
--disable-stripping
本スイッチは、ホスト上にある strip を使って、ビルドシステム内のプログラムのストリップを行わないようにします。 クロスコンパイルされたプログラムに対して、ホスト上のツールを使うと、ビルド失敗の原因になります。
--enable-widec
本スイッチは通常のライブラリ (libncurses.so.6.3
) ではなくワイド文字対応のライブラリ
(libncursesw.so.6.3
)
をビルドすることを指示します。 ワイド文字対応のライブラリは、マルチバイトロケールと従来の
8ビットロケールの双方に対して利用可能です。 通常のライブラリでは 8ビットロケールに対してしか動作しません。
ワイド文字対応と通常のものとでは、ソース互換があるもののバイナリ互換がありません。
パッケージをコンパイルします。
make
パッケージをインストールします。
make DESTDIR=$LFS TIC_PATH=$(pwd)/build/progs/tic install echo "INPUT(-lncursesw)" > $LFS/usr/lib/libncurses.so
install オプションの意味
TIC_PATH=$(pwd)/build/progs/tic
ビルドマシン上において、作り出したばかりの tic のパスを示すことが必要です。 こうすることで terminal データベースがエラーなく生成できることになります。
パッケージの中で、わずかですが libncurses.so
を必要としているものがあります。
これはすぐに生成する予定のものです。 ここでこの小さなリンカースクリプトを生成します。 これは
第 8 章 においてビルドします。
本パッケージの詳細は 「Ncurses の構成」を参照してください。
Bash は Bourne-Again SHell を提供します。
Bash をコンパイルするための準備をします。
./configure --prefix=/usr \ --build=$(support/config.guess) \ --host=$LFS_TGT \ --without-bash-malloc
configure オプションの意味
--without-bash-malloc
このオプションは Bash のメモリ割り当て関数 (malloc
) を利用しないことを指示します。
この関数はセグメンテーションフォールトが発生する可能性があるものとして知られています。
このオプションをオフにすることで、Bash は Glibc が提供する malloc
関数を用いるものとなり、そちらの方が安定しています。
パッケージをコンパイルします。
make
パッケージをインストールします。
make DESTDIR=$LFS install
他のプログラム類がシェルとして sh を用いるものがあるためリンクを作ります。
ln -sv bash $LFS/bin/sh
本パッケージの詳細は 「Bash の構成」を参照してください。
Coreutils パッケージはシステムの基本的な特性を表示したり設定したりするためのユーティリティを提供します。
Coreutils をコンパイルするための準備をします。
./configure --prefix=/usr \ --host=$LFS_TGT \ --build=$(build-aux/config.guess) \ --enable-install-program=hostname \ --enable-no-install-program=kill,uptime
configure オプションの意味
--enable-install-program=hostname
このオプションは hostname プログラムを生成しインストールすることを指示します。 このプログラムはデフォルトでは生成されません。 そしてこれは Perl のテストスイートを実行するのに必要となります。
パッケージをコンパイルします。
make
パッケージをインストールします。
make DESTDIR=$LFS install
プログラムを、最終的に期待されるディレクトリに移動させます。 この一時的環境にとっては必要なことではありませんが、これを実施するのは、実行モジュールの場所をハードコーディングしているプログラムがあるからです。
mv -v $LFS/usr/bin/chroot $LFS/usr/sbin mkdir -pv $LFS/usr/share/man/man8 mv -v $LFS/usr/share/man/man1/chroot.1 $LFS/usr/share/man/man8/chroot.8 sed -i 's/"1"/"8"/' $LFS/usr/share/man/man8/chroot.8
本パッケージの詳細は 「Coreutils の構成」を参照してください。
Diffutils パッケージはファイルやディレクトリの差分を表示するプログラムを提供します。
Diffutils をコンパイルするための準備をします。
./configure --prefix=/usr --host=$LFS_TGT
パッケージをコンパイルします。
make
パッケージをインストールします。
make DESTDIR=$LFS install
本パッケージの詳細は 「Diffutils の構成」を参照してください。
File パッケージは指定されたファイルの種類を決定するユーティリティを提供します。
ホストシステム上の file コマンドは、これから生成する同コマンドと同一バージョンでなければなりません。 これはシグニチャーファイル生成のために必要となります。 そこで以下のコマンドを実行してビルドします。
mkdir build pushd build ../configure --disable-bzlib \ --disable-libseccomp \ --disable-xzlib \ --disable-zlib make popd
configure オプションの意味
--disable-*
configure スクリプトは、ホスト上に特定のライブラリが存在するときに、それを利用しようとします。 ライブラリが存在していて、かつそれに対応するヘッダーファイルが存在していないときに、コンパイルに失敗することがあります。 このオプションは、そういったホストの機能は不要なので利用しないようにします。
File をコンパイルするための準備をします。
./configure --prefix=/usr --host=$LFS_TGT --build=$(./config.guess)
パッケージをコンパイルします。
make FILE_COMPILE=$(pwd)/build/src/file
パッケージをインストールします。
make DESTDIR=$LFS install
クロスコンパイルにとっては libtool アーカイブファイルが邪魔になるため削除します。
rm -v $LFS/usr/lib/libmagic.la
本パッケージの詳細は 「File の構成」を参照してください。
Findutils パッケージはファイル検索を行うプログラムを提供します。 このプログラムはディレクトリツリーを再帰的に検索したり、データベースの生成、保守、検索を行います。 (データベースによる検索は再帰的検索に比べて処理速度は速いものですが、データベースが最新のものに更新されていない場合は信頼できない結果となります。)
Findutils をコンパイルするための準備をします。
./configure --prefix=/usr \ --localstatedir=/var/lib/locate \ --host=$LFS_TGT \ --build=$(build-aux/config.guess)
パッケージをコンパイルします。
make
パッケージをインストールします。
make DESTDIR=$LFS install
本パッケージの詳細は 「Findutils の構成」を参照してください。
Gawk パッケージはテキストファイルを操作するプログラムを提供します。
はじめに、必要のないファイルはインストールしないようにします。
sed -i 's/extras//' Makefile.in
Gawk をコンパイルするための準備をします。
./configure --prefix=/usr \ --host=$LFS_TGT \ --build=$(build-aux/config.guess)
パッケージをコンパイルします。
make
パッケージをインストールします。
make DESTDIR=$LFS install
本パッケージの詳細は 「Gawk の構成」を参照してください。
Grep パッケージはファイル内の検索を行うプログラムを提供します。
Grep をコンパイルするための準備をします。
./configure --prefix=/usr \ --host=$LFS_TGT
パッケージをコンパイルします。
make
パッケージをインストールします。
make DESTDIR=$LFS install
本パッケージの詳細は 「Grep の構成」を参照してください。
Gzip パッケージはファイルの圧縮、伸長 (解凍) を行うプログラムを提供します。
Gzip をコンパイルするための準備をします。
./configure --prefix=/usr --host=$LFS_TGT
パッケージをコンパイルします。
make
パッケージをインストールします。
make DESTDIR=$LFS install
本パッケージの詳細は 「Gzip の構成」を参照してください。
Make パッケージは、対象となるパッケージのソースファイルを用いて、実行モジュールやそれ以外のファイルの生成、管理を行うプログラムを提供します。
Make をコンパイルするための準備をします。
./configure --prefix=/usr \ --without-guile \ --host=$LFS_TGT \ --build=$(build-aux/config.guess)
configure オプションの意味
--without-guile
ここではクロスコンパイルをしているにもかかわらず、ビルドホスト内に guile が存在すると configure がそれを見つけて利用しようとします。 そうなってしまうとコンパイルが失敗します。 そこで本スイッチにより、そうならないようにします。
パッケージをコンパイルします。
make
パッケージをインストールします。
make DESTDIR=$LFS install
本パッケージの詳細は 「Make の構成」を参照してください。
Patch パッケージは「パッチ」ファイルを適用することにより、ファイルの修正、生成を行うプログラムを提供します。 「パッチ」ファイルは diff プログラムにより生成されます。
Patch をコンパイルするための準備をします。
./configure --prefix=/usr \ --host=$LFS_TGT \ --build=$(build-aux/config.guess)
パッケージをコンパイルします。
make
パッケージをインストールします。
make DESTDIR=$LFS install
本パッケージの詳細は 「Patch の構成」を参照してください。
Sed パッケージはストリームエディターを提供します。
Sed をコンパイルするための準備をします。
./configure --prefix=/usr \ --host=$LFS_TGT
パッケージをコンパイルします。
make
パッケージをインストールします。
make DESTDIR=$LFS install
本パッケージの詳細は 「Sed の構成」を参照してください。
Tar パッケージは tar アーカイブの生成を行うとともに、アーカイブ操作に関する多くの処理を提供します。 Tar はすでに生成されているアーカイブからファイルを抽出したり、ファイルを追加したりします。 あるいはすでに保存されているファイルを更新したり一覧を表示したりします。
Tar をコンパイルするための準備をします。
./configure --prefix=/usr \ --host=$LFS_TGT \ --build=$(build-aux/config.guess)
パッケージをコンパイルします。
make
パッケージをインストールします。
make DESTDIR=$LFS install
本パッケージの詳細は 「Tar の構成」を参照してください。
Xz パッケージは、ファイルの圧縮、伸張 (解凍) を行うプログラムを提供します。 これは lzma フォーマットおよび新しい xz 圧縮フォーマットを取り扱います。 xz コマンドによりテキストファイルを圧縮すると、従来の gzip コマンドや bzip2 コマンドに比べて、高い圧縮率を実現できます。
Xz をコンパイルするための準備をします。
./configure --prefix=/usr \ --host=$LFS_TGT \ --build=$(build-aux/config.guess) \ --disable-static \ --docdir=/usr/share/doc/xz-5.2.6
パッケージをコンパイルします。
make
パッケージをインストールします。
make DESTDIR=$LFS install
クロスコンパイルにとっては libtool アーカイブファイルが邪魔になるため削除します。
rm -v $LFS/usr/lib/liblzma.la
本パッケージの詳細は 「Xz の構成」を参照してください。
Binutils パッケージは、リンカーやアセンブラーなどのようにオブジェクトファイルを取り扱うツール類を提供します。
Binutils の tarball では、古い libtool のコピーが提供されています。 これは sysroot サポートが行われていないので、ビルドされるバイナリが誤ってホストディストロのライブラリにリンクされてしまいます。 この問題を以下により回避します。
sed '6009s/$add_dir//' -i ltmain.sh
ビルドのためのディレクトリを再び生成します。
mkdir -v build cd build
Binutils をコンパイルするための準備をします。
../configure \ --prefix=/usr \ --build=$(../config.guess) \ --host=$LFS_TGT \ --disable-nls \ --enable-shared \ --enable-gprofng=no \ --disable-werror \ --enable-64-bit-bfd
configure オプションの意味
--enable-shared
libbfd
を共有ライブラリとしてビルドします。
--enable-64-bit-bfd
64 ビットサポートを有効にします(ホスト上にて、より小さなワードサイズとします)。 64 ビットシステムにおいては不要ですが、不具合を引き起こすものではありません。
パッケージをコンパイルします。
make
パッケージをインストールします。
make DESTDIR=$LFS install
クロスコンパイルにとっては libtool アーカイブファイルが邪魔になるため削除し、不要なスタティックライブラリも削除します。
rm -v $LFS/usr/lib/lib{bfd,ctf,ctf-nobfd,opcodes}.{a,la}
本パッケージの詳細は 「Binutils の構成」を参照してください。
GCC パッケージは C コンパイラーや C++ コンパイラーなどの GNU コンパイラーコレクションを提供します。
GCC の 1 回めのビルドと同様に、ここでも GMP、MPFR、MPC の各パッケージを必要とします。 tarball を解凍して、所定のディレクトリ名に移動させます。
tar -xf ../mpfr-4.1.0.tar.xz mv -v mpfr-4.1.0 mpfr tar -xf ../gmp-6.2.1.tar.xz mv -v gmp-6.2.1 gmp tar -xf ../mpc-1.2.1.tar.gz mv -v mpc-1.2.1 mpc
x86_64 上でビルドしている場合は、64ビットライブラリのデフォルトディレクトリ名を「lib」にします。
case $(uname -m) in x86_64) sed -e '/m64=/s/lib64/lib/' -i.orig gcc/config/i386/t-linux64 ;; esac
libgcc と libstdc++ のヘッダーのビルドルールを変更して、これらのライブラリに対して POSIX スレッドサポートを含めてビルドするようにします。
sed '/thread_header =/s/@.*@/gthr-posix.h/' \ -i libgcc/Makefile.in libstdc++-v3/include/Makefile.in
専用のディレクトリを再度生成します。
mkdir -v build cd build
GCC のビルドに入る前に、デフォルトの最適化フラグを上書きするような環境変数の設定がないことを確認してください。
GCC をコンパイルするための準備をします。
../configure \ --build=$(../config.guess) \ --host=$LFS_TGT \ --target=$LFS_TGT \ LDFLAGS_FOR_TARGET=-L$PWD/$LFS_TGT/libgcc \ --prefix=/usr \ --with-build-sysroot=$LFS \ --enable-initfini-array \ --disable-nls \ --disable-multilib \ --disable-decimal-float \ --disable-libatomic \ --disable-libgomp \ --disable-libquadmath \ --disable-libssp \ --disable-libvtv \ --enable-languages=c,c++
configure オプションの意味
--with-build-sysroot=$LFS
通常は --host
を用いれば、GCC ビルドにクロスコンパイラーが用いられ、参照すべきヘッダーやライブラリも
$LFS
にあるものが用いられるように指示されます。 しかし今ビルドを行っているシステム上の GCC
は別のツールを使っているので、上のような場所を認識できていません。
本スイッチは、必要なファイルをホスト内からではなく、$LFS
から探し出すようにします。
--target=$LFS_TGT
これまでの GCC はクロスコンパイルによって作り出してきているので、コンパイル済み GCC
実行ファイルからターゲットライブラリ(libgcc
と libstdc++
)
をビルドして作り出すことができません。
なぜならその実行ファイルはホストディストリビューション上で動作させられないからです。 GCC
ビルドシステムはその回避策として、デフォルトではホスト上にある C および C++
コンパイラーを利用しようとします。 ただし GCC のバージョンが異なる場合に、GCC
ターゲットライブラリをビルドすることはサポートされていません。
したがってホスト上のコンパイラーがビルドに失敗する可能性があります。 本パラメーターは、確実に GCC
1回めの実行ファイルを使ってライブラリビルドを行うようにして、問題が発生しないようにします。
LDFLAGS_FOR_TARGET=...
GCC 1回めではスタティックバージョンの libgcc
をビルドしていましたが、ここでは共有の
libgcc
をビルドするようにします。 これは
C++ 例外処理のために必要となります。
--enable-initfini-array
本オプションを指定すれば、自動的に x86 上のネイティブコンパイラーを使って、ネイティブコンパイラーをビルドするようにします。 しかしここではクロスコンパイラーを作り出すつもりでいます。 したがって明示的に本オプションへ指定が必要になります。
パッケージをコンパイルします。
make
パッケージをインストールします。
make DESTDIR=$LFS install
最後に、便利なシンボリックリンクを作成します。 プログラムやスクリプトの中には gcc ではなく cc を用いるものが結構あります。 シンボリックリンクを作ることで各種のプログラムを汎用的にすることができ、通常 GNU C コンパイラーがインストールされていない多くの UNIX システムでも利用できるものになります。 cc を利用することにすれば、システム管理者がどの C コンパイラーをインストールすべきかを判断する必要がなくなります。
ln -sv gcc $LFS/usr/bin/cc
本パッケージの詳細は 「GCC の構成」を参照してください。
本章では、一時的システムに足りていない最後の部分をビルドしていきます。 つまり、多くのパッケージビルドに必要となるツールをビルドします。 こうして循環的な相互参照の関係が解決するので、これまで利用してきたホストオペレーティングシステムから完全に離れて(実行中のカーネルは除きますが)"chroot" 環境に入って、 ビルドを行っていきます。
chroot 環境内では適切な操作とするため、実行されているカーネルとのやり取りを確実に行います。 それはいわゆる 仮想カーネルファイルシステム を通じて行うものです。 chroot 環境に入る際には、あらかじめマウントされていなければなりません。 マウントがされているかどうかを確認する場合は findmnt を実行します。
「Chroot 環境への移行」 まで、コマンドの実行は
LFS
を設定した上で、root
ユーザーにより行う必要があります。 chroot
環境に入っても、コマンドはすべて root
実行ですが、もう安心です。 LFS を構築しているコンピューター上の OS にはもうアクセスしないからです。
かと言ってコマンド実行を誤れば、簡単に LFS システムを壊してしまうことになりますから、十分に注意してください。
本書のこれ以降で実行するコマンドはすべて root
ユーザーでログインして実行します。 もう lfs
ユーザーは不要です。 root
ユーザーの環境にて環境変数
$LFS
がセットされていることを今一度確認してください。
$LFS
ディレクトリ配下の所有者は今は lfs
ユーザーであり、これはホストシステム上にのみ存在するユーザーです。 この
$LFS
ディレクトリ配下をこのままにしておくということは、そこにあるファイル群が、存在しないユーザーによって所有される形を生み出すことになります。
これは危険なことです。 後にユーザーアカウントが生成され同一のユーザーIDを持ったとすると $LFS
の全ファイルの所有者となるので、悪意のある操作に利用されてしまいます。
この問題を解消するために $LFS/*
ディレクトリの所有者を
root
ユーザーにします。
以下のコマンドによりこれを実現します。
chown -R root:root $LFS/{usr,lib,var,etc,bin,sbin,tools} case $(uname -m) in x86_64) chown -R root:root $LFS/lib64 ;; esac
カーネルが取り扱うさまざまなファイルシステムは、カーネルとの間でやり取りが行われます。 これらのファイルシステムは仮想的なものであり、ディスクを消費するものではありません。 ファイルシステムの内容はメモリ上に保持されます。
ファイルシステムをマウントするディレクトリを以下のようにして生成します。
mkdir -pv $LFS/{dev,proc,sys,run}
通常のブートの際には、カーネルは /dev
ディレクトリ上に
devtmpfs
ファイルシステムを自動的にマウントします。
そしてデバイスが検出されたりアクセスされたりするたびに、デバイスが仮想ファイルシステムを動的生成できるようにしています。
このデバイス生成処理は一般的には、システム起動時にカーネルと Udev によって行われます。 今構築中のシステムにはまだ
Udev を導入していませんし、再起動も行っていませんので /dev
のマウントと有効化は手動で行ないます。 これはホストシステムの
/dev
ディレクトリに対して、バインドマウントを行うことで実現します。 バインドマウント (bind mount)
は特殊なマウント方法の一つで、ディレクトリのミラーを生成したり、他のディレクトリへのマウントポイントを生成したりします。
以下のコマンドにより実現します。
mount -v --bind /dev $LFS/dev
残りの仮想カーネルファイルシステムを以下のようにしてマウントします。
mount -v --bind /dev/pts $LFS/dev/pts mount -vt proc proc $LFS/proc mount -vt sysfs sysfs $LFS/sys mount -vt tmpfs tmpfs $LFS/run
ホストシステムによっては /dev/shm
が
/run/shm
へのシンボリックリンクになっているものがあります。 上の作業にて /run tmpfs
がマウントされましたが、これはこのディレクトリを生成する必要がある時のみです。
if [ -h $LFS/dev/shm ]; then mkdir -pv $LFS/$(readlink $LFS/dev/shm) fi
残るツール類をビルドするために必要なパッケージは、ここまでにすべてビルドしました。 そこで chroot
環境に入って、残りの一時的ツールをインストールしていきます。
この環境は、最終システムに向けたインストールを行う際にも用います。 root
ユーザーになって以下のコマンドを実行します。 chroot
環境内は、この時点では一時的なツール類のみが利用可能な状態です。
chroot "$LFS" /usr/bin/env -i \ HOME=/root \ TERM="$TERM" \ PS1='(lfs chroot) \u:\w\$ ' \ PATH=/usr/bin:/usr/sbin \ /bin/bash --login
env コマンドの
-i
パラメーターは、chroot
環境での変数定義をすべてクリアするものです。 そして HOME
,
TERM
, PS1
, PATH
という変数だけここで定義し直します。 TERM=$TERM
は chroot 環境に入る前と同じ値を
TERM
変数に与えます。 この設定は vim や less
のようなプログラムの処理が適切に行われるために必要となります。 これ以外の変数として CFLAGS
や CXXFLAGS
などが必要であれば、ここで定義しておくと良いでしょう。
ここから先は LFS
変数は不要となります。 すべての作業は LFS
ファイルシステム内で行っていくことになるからです。 起動される Bash シェルは $LFS
ディレクトリがルート (/
ディレクトリ) となって動作します。
/tools/bin
が PATH
内には存在しません。 つまりクロスチェーンは chroot
環境内ではもはや利用しないということです。
bash のプロンプトに
I have no name!
と表示されますがこれは正常です。 この時点ではまだ /etc/passwd
を生成していないからです。
本章のこれ以降と次章では、すべてのコマンドを chroot 環境内にて実行することが必要です。 例えばシステムを再起動する場合のように chroot 環境からいったん抜け出した場合には、「/dev のマウントと有効化」と 「仮想カーネルファイルシステムのマウント」にて説明した仮想カーネルファイルシステムがマウントされていることを確認してください。 そして chroot 環境に入り直してからインストール作業を再開してください。
LFS ファイルシステムにおける完全なディレクトリ構成を作り出していきます。
本節において触れるディレクトリの中には、明示的な指示か、あるいは何かのパッケージインストールによってすでに生成済みであるものがあります。 以下では完全を期して繰り返し生成することにします。
ルートレベルのディレクトリをいくつか生成します。 これは前章において必要としていた限定的なものの中には含まれていないものです。 以下のコマンドを実行して生成します。
mkdir -pv /{boot,home,mnt,opt,srv}
ルートレベル配下に、必要となる一連のサブディレクトリを、以下のコマンドにより生成します。
mkdir -pv /etc/{opt,sysconfig} mkdir -pv /lib/firmware mkdir -pv /media/{floppy,cdrom} mkdir -pv /usr/{,local/}{include,src} mkdir -pv /usr/local/{bin,lib,sbin} mkdir -pv /usr/{,local/}share/{color,dict,doc,info,locale,man} mkdir -pv /usr/{,local/}share/{misc,terminfo,zoneinfo} mkdir -pv /usr/{,local/}share/man/man{1..8} mkdir -pv /var/{cache,local,log,mail,opt,spool} mkdir -pv /var/lib/{color,misc,locate} ln -sfv /run /var/run ln -sfv /run/lock /var/lock install -dv -m 0750 /root install -dv -m 1777 /tmp /var/tmp
ディレクトリは標準ではパーミッションモード 755
で生成されますが、すべてのディレクトリをこのままとするのは適当ではありません。
上のコマンド実行ではパーミッションを変更している箇所が二つあります。 一つは root
ユーザーのホームディレクトリに対してであり、もう一つはテンポラリディレクトリに対してです。
パーミッションモードを変更している一つめは /root
ディレクトリに対して、他のユーザーによるアクセスを制限するためです。
通常のユーザーが持つ、自分自身のホームディレクトリへのアクセス権設定と同じことを行ないます。 二つめのモード変更は
/tmp
ディレクトリや /var/tmp
ディレクトリに対して、どのユーザーも書き込み可能とし、ただし他のユーザーが作成したファイルは削除できないようにします。
ビットマスク 1777 の最上位ビット、いわゆる「スティッキービット (sticky bit)」を用いて実現します。
本書のディレクトリ構成は標準ファイルシステム構成 (Filesystem Hierarchy Standard; FHS)
に基づいています。(その情報は https://refspecs.linuxfoundation.org/fhs.shtml
に示されています。) FHS では、任意のディレクトリとして /usr/local/games
や /usr/share/games
などを規定しています。
したがって本書では必要なディレクトリのみを作成していくことにします。
他のディレクトリについては、どうぞ自由に取り決めて作成してください。
Linux のこれまでの経緯として、マウントされているファイルシステムの情報は /etc/mtab
ファイルに保持されています。 最新の Linux
であれば、内部的にこのファイルを管理し、ユーザーに対しては /proc
ファイルシステムを通じて情報提示しています。 /etc/mtab
ファイルの存在を前提としているプログラムが正常動作するように、以下のシンボリックリンクを作成します。
ln -sv /proc/self/mounts /etc/mtab
テストスイートの中に /etc/hosts
ファイルを参照するものがあるので、単純なものをここで生成します。 これは Perl の設定ファイルにおいても参照されます。
cat > /etc/hosts << EOF 127.0.0.1 localhost $(hostname) ::1 localhost EOF
root
ユーザーがログインできるように、またその「root」という名称を認識できるように /etc/passwd
ファイルと /etc/group
ファイルには該当する情報が登録されている必要があります。
以下のコマンドを実行して /etc/passwd
ファイルを生成します。
cat > /etc/passwd << "EOF"
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/dev/null:/usr/bin/false
daemon:x:6:6:Daemon User:/dev/null:/usr/bin/false
messagebus:x:18:18:D-Bus Message Daemon User:/run/dbus:/usr/bin/false
systemd-journal-gateway:x:73:73:systemd Journal Gateway:/:/usr/bin/false
systemd-journal-remote:x:74:74:systemd Journal Remote:/:/usr/bin/false
systemd-journal-upload:x:75:75:systemd Journal Upload:/:/usr/bin/false
systemd-network:x:76:76:systemd Network Management:/:/usr/bin/false
systemd-resolve:x:77:77:systemd Resolver:/:/usr/bin/false
systemd-timesync:x:78:78:systemd Time Synchronization:/:/usr/bin/false
systemd-coredump:x:79:79:systemd Core Dumper:/:/usr/bin/false
uuidd:x:80:80:UUID Generation Daemon User:/dev/null:/usr/bin/false
systemd-oom:x:81:81:systemd Out Of Memory Daemon:/:/usr/bin/false
nobody:x:65534:65534:Unprivileged User:/dev/null:/usr/bin/false
EOF
root
ユーザーに対する本当のパスワードは後に定めます。
以下のコマンドを実行して /etc/group
ファイルを生成します。
cat > /etc/group << "EOF"
root:x:0:
bin:x:1:daemon
sys:x:2:
kmem:x:3:
tape:x:4:
tty:x:5:
daemon:x:6:
floppy:x:7:
disk:x:8:
lp:x:9:
dialout:x:10:
audio:x:11:
video:x:12:
utmp:x:13:
usb:x:14:
cdrom:x:15:
adm:x:16:
messagebus:x:18:
systemd-journal:x:23:
input:x:24:
mail:x:34:
kvm:x:61:
systemd-journal-gateway:x:73:
systemd-journal-remote:x:74:
systemd-journal-upload:x:75:
systemd-network:x:76:
systemd-resolve:x:77:
systemd-timesync:x:78:
systemd-coredump:x:79:
uuidd:x:80:
systemd-oom:x:81:
wheel:x:97:
users:x:999:
nogroup:x:65534:
EOF
作成するグループは何かの標準に基づいたものではありません。 一部は 9 章の udev
の設定に必要となるものですし、一部は既存の Linux ディストリビューションが採用している慣用的なものです。
またテストスイートにて特定のユーザーやグループを必要としているものがあります。 Linux Standard Base
(http://www.linuxbase.org 参照) では
root
グループのグループID (GID) は
0、bin
グループの GID は 1
を定めているにすぎません。 GID 5 は tty
グループに対して広く用いられています。 また数値 5 は devpts
ファイルシステムに対して systemd においても用いられています。 他のグループとその GID
はシステム管理者が自由に取り決めることができます。 というのも通常のプログラムであれば GID
の値に依存することはなく、あくまでグループ名を用いてプログラミングされているからです。
ID 65534 は NFS のカーネルが利用し、マップされていないユーザーやグループに対するユーザー名前空間を切り分けます
(これは NFS サーバー上や親のユーザー空間に存在しますが、ローカルマシンや分離された名前空間には存在しません)。
未割り当ての ID を避けるために、この ID を nobody
と nogroup
に用いることにします。 他のディストリビューションにおいては、この
ID を異なる用い方をしている場合があるため、移植性を考慮するプログラムでは、ここでの割り当てに依存しないようにしてください。
第 8 章 におけるテストの中には、通常のユーザーを必要とするものがあります。 ここでそういったユーザーをここで追加し、その章の最後には削除します。
echo "tester:x:101:101::/home/tester:/bin/bash" >> /etc/passwd echo "tester:x:101:" >> /etc/group install -o tester -d /home/tester
プロンプトの「I have no
name!」を取り除くために新たなシェルを起動します。 /etc/passwd
ファイルと /etc/group
ファイルを作ったので、ユーザー名とグループ名の名前解決が適切に動作します。
exec /usr/bin/bash --login
login、agetty、init といったプログラム (あるいは他のプログラム) は、システムに誰がいつログインしたかといった情報を多くのログファイルに記録します。 しかしログファイルがあらかじめ存在していない場合は、ログファイルの出力が行われません。 そこでそのようなログファイルを作成し、適切なパーミッションを与えます。
touch /var/log/{btmp,lastlog,faillog,wtmp} chgrp -v utmp /var/log/lastlog chmod -v 664 /var/log/lastlog chmod -v 600 /var/log/btmp
/var/log/wtmp
ファイルはすべてのログイン、ログアウトの情報を保持します。 /var/log/lastlog
ファイルは各ユーザーが最後にログインした情報を保持します。 /var/log/faillog
ファイルはログインに失敗した情報を保持します。
/var/log/btmp
ファイルは不正なログイン情報を保持します。
/run/utmp
ファイルは現在ログインしているユーザーの情報を保持します。 このファイルはブートスクリプトが動的に生成します。
Gettext パッケージは国際化を行うユーティリティを提供します。 各種プログラムに対して NLS (Native Language Support) を含めてコンパイルすることができます。 つまり各言語による出力メッセージが得られることになります。
ここで構築している一時的なツールに際して、Gettext パッケージからは3つのバイナリをインストールするだけで十分です。
Gettext をコンパイルするための準備をします。
./configure --disable-shared
configure オプションの意味
--disable-shared
Gettext の共有ライブラリはこの時点では必要でないため、それらをビルドしないようにします。
パッケージをコンパイルします。
make
msgfmt, msgmerge, xgettext の各プログラムをインストールします。
cp -v gettext-tools/src/{msgfmt,msgmerge,xgettext} /usr/bin
本パッケージの詳細は 「Gettext の構成」を参照してください。
Bison パッケージは構文解析ツールを提供します。
Bison をコンパイルするための準備をします。
./configure --prefix=/usr \ --docdir=/usr/share/doc/bison-3.8.2
configure オプションの意味
--docdir=/usr/share/doc/bison-3.8.2
ビルドシステムに対して、bison のドキュメントをインストールするディレクトリを、バージョンつきとします。
パッケージをコンパイルします。
make
パッケージをインストールします。
make install
本パッケージの詳細は 「Bison の構成」を参照してください。
Perl パッケージは Perl 言語 (Practical Extraction and Report Language) を提供します。
Perl をコンパイルするための準備をします。
sh Configure -des \ -Dprefix=/usr \ -Dvendorprefix=/usr \ -Dprivlib=/usr/lib/perl5/5.36/core_perl \ -Darchlib=/usr/lib/perl5/5.36/core_perl \ -Dsitelib=/usr/lib/perl5/5.36/site_perl \ -Dsitearch=/usr/lib/perl5/5.36/site_perl \ -Dvendorlib=/usr/lib/perl5/5.36/vendor_perl \ -Dvendorarch=/usr/lib/perl5/5.36/vendor_perl
Configure オプションの意味
-des
これは三つのオプションを組み合わせたものです。 -d はあらゆる項目に対してデフォルト設定を用います。 -e はタスクをすべて実施します。 -s は不要な出力は行わないようにします。
パッケージをコンパイルします。
make
パッケージをインストールします。
make install
本パッケージの詳細は 「Perl の構成」を参照してください。
Python 3 パッケージは Python 開発環境を提供します。 オブジェクト指向プログラミング、スクリプティング、大規模プログラムのプロトタイピング、アプリケーション開発などに有用なものです。
「python」の名前で始まるパッケージファイルは 2 種類あります。
そのうち、扱うべきファイルは Python-3.10.6.tar.xz
です。 (1
文字めが大文字であるものです。)
Python をコンパイルするための準備をします。
./configure --prefix=/usr \ --enable-shared \ --without-ensurepip
configure パラメーターの意味
--enable-shared
このスイッチはスタティックライブラリをインストールしないようにします。
--without-ensurepip
このスイッチは Python パッケージインストーラーを無効にします。 この段階では必要がないからです。
パッケージをコンパイルします。
make
この時点において、依存パッケージをまだインストールしていないために、ビルドできない Python 3 モジュールがあります。 それでもビルドシステムは、そのようなモジュールをビルドしようとします。 そして一部のファイルのコンパイルが失敗して、コンパイラーメッセージには「致命的エラー」が示されます。 このメッセージは無視できます。 よく確認すべきなのは、トップレベルの make コマンドは失敗していないことです。 任意でビルドすれば良いモジュールは、今ここでのビルドは必要ありません。 それは、この後に 第 8 章 においてビルドされます。
パッケージをインストールします。
make install
本パッケージの詳細は 「Python 3 の構成」を参照してください。
Texinfo パッケージは info ページへの読み書き、変換を行うプログラムを提供します。
Texinfo をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルします。
make
パッケージをインストールします。
make install
本パッケージの詳細は 「Texinfo の構成」を参照してください。
Util-linux パッケージはさまざまなユーティリティープログラムを提供します。
FHS では adjtime
ファイルの配置場所として
/etc
ディレクトリではなく /var/lib/hwclock
ディレクトリを推奨しています。
そこで以下によりそのディレクトリを生成します。
mkdir -pv /var/lib/hwclock
Util-linux をコンパイルするための準備をします。
./configure ADJTIME_PATH=/var/lib/hwclock/adjtime \ --libdir=/usr/lib \ --docdir=/usr/share/doc/util-linux-2.38.1 \ --disable-chfn-chsh \ --disable-login \ --disable-nologin \ --disable-su \ --disable-setpriv \ --disable-runuser \ --disable-pylibmount \ --disable-static \ --without-python \ runstatedir=/run
configure オプションの意味
ADJTIME_PATH=/var/lib/hwclock/adjtime
これはハードウェアクロックの情報を保持したファイルの場所を設定するものであり、FHS に従ったものです。 一時的なツールにとって厳密には必要ではありませんが、別の場所にはファイル生成するわけにはいきません。 最終的な util-linux パッケージをビルドする際に、上書きしたり削除したりすることができなくなるからです。
--libdir=/usr/lib
本スイッチは、共有ライブラリを示す .so
シンボリックリンクを同一ディレクトリ(/usr/lib
)に直接生成するようにします。
--disable-*
コンポーネントのビルドの際に、LFS にはない、あるいはまだインストールしていない別のパッケージがあり、そのために発生する警告メッセージを無効にします。
--without-python
本スイッチは Python を用いないようにします。 ビルドの際に不要なバインディングを作らないようにするためです。
runstatedir=/run
本スイッチは uuidd や libuuid
が利用するソケットの場所を適切に設定します。
パッケージをコンパイルします。
make
パッケージをインストールします。
make install
本パッケージの詳細は 「Util-linux の構成」を参照してください。
はじめに、現在インストールされているドキュメントは削除します。 これを最終的なシステムに持ち込みません。 これによって 35 MB を節約します。
rm -rf /usr/share/{info,man,doc}/*
libtool の .la ファイルはスタティックライブラリにリンクするときだけ使います。 これらはダイナミック共有ライブラリを用いるとき、そして特に autotools 以外のビルドシステムを利用するときには不要であり、潜在的には支障を及ぼします。 したがって chroot の中で、不要なファイルは削除します。
find /usr/{lib,libexec} -name \*.la -delete
現在のシステムサイズは、およそ 3 GB になりました。 そして /tools ディレクトリは、もう必要がありません。 ディスク容量は 1 GB 近くを占めています。 ここで削除します。
rm -rf /tools
この時点において、基本的なプログラムやライブラリが生成されたので、現在の LFS システムの状態は良好なものです。 このシステムを、後に再利用できるように、ここでバックアップを取ることができます。 ここから先の章において、致命的な失敗をしてしまった場合は、すべてを削除して (今度はより慎重に) やり直すのが、一番のやり方であるのは、明らかです。 ただし、そのときには一時システムも失ってしまっている状態です。 余計な時間を費やすことなく、ビルドに成功したところまでのシステムを使ってやり直す策を考えるのであれば、ここで LFS システムのバックアップをとっておくことが、後々の役に立つかもしれません。
本節の残りの作業は必須ではありません。 ただし 第 8 章 においてパッケージのインストールを始めていくと、一時的ツールは上書きされていきます。 そこで以下に示すように、現時点でのシステムのバックアップをとっておくのが良いでしょう。
以下の手順は chroot 環境の外から実施します。 これはつまり chroot
環境から抜け出してから手順を進めていくということです。
こうする理由は、バックアップアーカイブの保存や読み込みをするなら、ファイルシステムへのアクセスは chroot
環境の外部から行うべきであって、安全のため $LFS
ディレクトリ階層の内部において行うべきではないからです。
バックアップを取ることにしているのであれば、 ここで chroot 環境から抜け出ます。
exit
以降の手順はすべて、ホストシステム上の root
ユーザーにより実施します。 特にコマンド実行は、よく注意しながら行ってください。
誤ったことをすると、ホストシステムを書き換えてしまうことになります。 環境変数 LFS
はデフォルトで lfs
ユーザーにおいて設定していましたが、root
ユーザーにおいては設定していないかもしれません。
root
ユーザーによってコマンド実行する際にも、必ず
LFS
が設定されていることを確認してください。
このことは 「変数 $LFS の設定」 において説明済です。
バックアップを取る前には、仮想ファイルシステムをアンマウントします。
umount $LFS/dev/pts umount $LFS/{sys,proc,run,dev}
バックアップアーカイブを生成したディレクトリを含むファイルシステムにおいて、未使用のディスク容量が最低でも 1 GB はあることを確認してください。 (ソース tarball もバックアップアーカイブに含めます。)
なお、これ以降の手順説明においては、ホストシステム上の root
ユーザーのホームディレクトリを用いています。
これは通常、ルートファイルシステムに置かれているものです。
root
ユーザーのホームディレクトリにバックアップを生成したくない場合は、$HOME
の内容を適切に書き換えてください。
バックアップアーカイブを生成するために、以下のコマンドを実行します。
バックアップアーカイブは圧縮するので、かなりの高速なシステムを利用していても、比較的長い時間 (10 分以上) を要します。
cd $LFS tar -cJpf $HOME/lfs-temp-tools-11.2-systemd.tar.xz .
第 8 章を続けるのであれば、以降に示す「重要」の説明のように、chroot 環境に再度入ることを忘れないでください。
誤操作をしてしまい、初めからやり直す必要が出てきたとします。
そんなときは上のバックアップを復元し、すばやく回復させることにしましょう。 $LFS
配下にソースも配置することにしているので、バックアップアーカイブ内にはそれらも含まれています。
したがって再度ダウンロードする必要はありません。 $LFS
が適切に設定されていることを再度確認した上で、バックアップの復元を行うための以下のコマンドを実行します。
以下に示すコマンドは相当に危険です。 root
ユーザーになって rm -rf
./* を実行する際に、$LFS ディレクトリに移動していない、あるいは環境変数
LFS
を設定していないとしたら、システム全体を破壊することになります。 厳に警告しておきます。
cd $LFS
rm -rf ./*
tar -xpf $HOME/lfs-temp-tools-11.2-systemd.tar.xz
環境変数が適切に設定されていることを再度確認の上、ここから続くシステムビルドに進んでいきます。
chroot 環境から抜け出して、バックアップの生成を行った場合、あるいはビルド作業を再開する場合は、「仮想カーネルファイルシステムの準備」 において説明している、カーネル仮想ファイルシステムがマウントされていることを確認してください (findmnt | grep $LFS)。 もしマウントされていなかったら、マウントを行ってから、再び chroot 環境に入るようにしてください(「Chroot 環境への移行」 参照)。
この章では LFS システムの構築作業を始めます。
パッケージ類のインストール作業は簡単なものです。 インストール手順の説明は、たいていは手短に一般的なものだけで済ますこともできます。 ただ誤りの可能性を極力減らすために、個々のインストール手順の説明は十分に行うことにします。 Linux システムがどのようにして動作しているかを学ぶには、個々のパッケージが何のために用いられていて、なぜユーザー (あるいはシステム) がそれを必要としているのかを知ることが重要になります。
コンパイラーには最適化オプションがありますが、これを利用することはお勧めしません。
コンパイラーの最適化を用いればプログラムが若干速くなる場合もありますが、そもそもコンパイルが出来なかったり、プログラムの実行時に問題が発生したりする場合があります。
もしコンパイラーの最適化によってパッケージビルドが出来なかったら、最適化をなしにしてもう一度コンパイルすることで解決するかどうかを確認してください。
最適化を行ってパッケージがコンパイル出来たとしても、コードとビルドツールの複雑な関連に起因してコンパイルが適切に行われないリスクをはらんでいます。
また -march
オプションや -mtune
オプションにて指定する値は、本書には明示しておらずテストも行っていませんので注意してください。
これらはツールチェーンパッケージ (Binutils、GCC、Glibc) に影響を及ぼすことがあります。
最適化オプションを用いることによって得られるものがあったとしても、それ以上にリスクを伴うことがしばしばです。 初めて LFS
構築を手がける方は、最適化オプションをなしにすることをお勧めします。
これ以降にビルドしていくツール類は、それでも十分に速く安定して動作するはずです。
各ページではインストール手順の説明よりも前に、パッケージの内容やそこに何が含まれているかを簡単に説明し、ビルドにどれくらいの時間を要するか、ビルド時に必要となるディスク容量はどれくらいかを示しています。 またインストール手順の最後には、パッケージがインストールするプログラムやライブラリの一覧を示し、それらがどのようなものかを簡単に説明しています。
第 8 章 にて導入するパッケージにおいて SBU 値と必要ディスク容量には、テストスイート実施による時間や容量をすべて含んでいます。 なお SBU 値はすべて、単一の CPU コア(-j1)を用いて算出しています。
LFS 編集者は全般にスタティックライブラリは作らないものとしています。 スタティックライブラリが作られたそもそもの目的は、現在の Linux システムにとってはもはや古いものです。 スタティックライブラリをリンクすると障害となることすらあります。 例えばセキュリティ問題を解決するためにライブラリリンクを更新しなければならなくなったら、スタティックライブラリにリンクしていたプログラムはすべて再構築しなければなりません。 したがってスタティックライブラリを使うべきかどうかは、いつも迷うところであり、関連するプログラム (あるいはリンクされるプロシージャ) であってもどちらかに定めなければなりません。
本章の手順では、スタティックライブラリのインストールはたいてい行わないようにしています。 多くのケースでは
configure に対して
--disable-static
を与えることで実現しますが、これができない場合には他の方法を取ります。 ただし glibc や gcc
においては、一般的なパッケージビルドに必要であるため、スタティックライブラリを利用します。
ライブラリに関してのより詳細な議論については BLFS ブックの Libraries: Static or shared? を参照してください。
パッケージ管理についての説明を LFS ブックに加えて欲しいとの要望をよく頂きます。 パッケージ管理ツールがあれば、インストールされるファイル類を管理し、パッケージの削除やアップグレードを容易に実現できます。 パッケージ管理ツールでは、バイナリファイルやライブラリファイルだけでなく、設定ファイル類のインストールも取り扱います。 パッケージ管理ツールをどうしたら・・・ いえいえ本節は特定のパッケージ管理ツールを説明するわけでなく、その利用を勧めるものでもありません。 もっと広い意味で、管理手法にはどういったものがあり、どのように動作するかを説明します。 あなたにとって最適なパッケージ管理がこの中にあるかもしれません。 あるいはそれらをいくつか組み合わせて実施することになるかもしれません。 本節ではパッケージのアップグレードを行う際に発生する問題についても触れます。
LFS や BLFS においてパッケージ管理ツールに触れていない理由には以下のものがあります。
本書の目的は Linux システムがいかに構築されているかを学ぶことです。 パッケージ管理はその目的からはずれてしまいます。
パッケージ管理についてはいくつもの方法があり、それらには一長一短があります。 ユーザーに対して満足のいくものを選び出すのは困難です。
ヒントプロジェクト (Hints Project) ページにパッケージ管理についての情報が示されています。 望むものがあるかどうか確認してみてください。
パッケージ管理ツールがあれば、各種ソフトウェアの最新版がリリースされた際に容易にアップグレードができます。 全般に LFS ブックや BLFS ブックに示されている作業手順に従えば、新しいバージョンへのアップグレードを行っていくことはできます。 以下ではパッケージをアップグレードする際に注意すべき点、特に稼動中のシステムに対して実施するポイントについて説明します。
カーネルをアップグレードする必要がある場合 (たとえば 5.10.17 から 5.10.18 や 5.11.1 へ、など)、これ以外に再ビルドを必要とするものはありません。 カーネルとユーザー空間の境界が適切に定義されているため、システムは動作し続けるはずです。 特に Linux API ヘッダーは、カーネルに伴ってアップグレードする必要もありません (次に説明するように、アップグレードしてはなりません)。 アップグレードしたカーネルは、システムを再起動すれば利用できるようになります。
Linux API ヘッダーや Glibc を新しいバージョン (例えば glibc-2.31 から glibc-2.32) にアップグレードする必要が発生した場合は LFS を再構築することが安全です。 必要なパッケージの依存順を知っていれば再構築できるかもしれませんが、これはお勧めしません。
共有ライブラリを提供しているパッケージをアップデートする場合で、そのライブラリ名が変更になったとします。
この場合は、このライブラリに動的リンクを行っていたパッケージは、新たなライブラリに向けてのリンクとなるように再コンパイルすることが必要になります。
(なおパッケージバージョンとライブラリ名には関連性はありません。) たとえば foo-1.2.3
というパッケージがあって、これが共有ライブラリ libfoo.so.1
をインストールしているとします。
そして新バージョン foo-1.2.4 が共有ライブラリ libfoo.so.2
を持っていて、これにアップグレードするものとします。 この場合 libfoo.so.1
に動的リンクを行っていたパッケージは、すべて新ライブラリバージョン libfoo.so.2
へのリンクを行うように再コンパイルしなければなりません。
そのように依存していたパッケージをすべて再コンパイルしてからでないと、古いバージョンのライブラリは削除するべきではありません。
共有ライブラリを提供しているパッケージをアップデートする場合で、そのライブラリ名には変更がなかったとします。
ただしライブラリ名の変更はなくても、ライブラリファイルのバージョン番号が減らされたとします。
(たとえばライブラリ名 libfoo.so.1
はそのまま不変であったとして、ライブラリファイル名が libfoo.so.1.25
から libfoo.so.1.24
に変更となった場合です。)
この場合、それまでインストールされていたバージョン(例では libfoo.so.1.25
)のライブラリファイルは削除すべきです。
そうしておかないと、ldconfig
を実行したときに(自分でコマンドライン実行したり、別のパッケージをインストールする際に実施されたりしたときに)、シンボリックリンク
libfoo.so.1
がリセットされますが、それが指し示す先が古いライブラリファイルとなってしまいます。
なぜならバージョン番号がより大きい方なので、そのバージョンの方が「より新しい」と解釈されるためです。
こういった状況は、パッケージをダウングレードした場合や、パッケージにおけるバージョン番号づけの取り決めが突然変わってしまった場合に起こり得るものです。
共有ライブラリを提供しているパッケージをアップデートする場合で、そのライブラリ名に変更はなかったとします。
ただしそこでは重大な問題(特にセキュリティぜい弱性)が解消されているような場合は、この共有ライブラリにリンクしている実行中プログラムは、すべて再起動してください。
アップグレードした後に、以下のコマンドを root
で実行すると、どういったプログラムが古いバージョンのライブラリを利用しているかの一覧が表示されます。
(libfoo
の部分は、目的のライブラリ名に置き換えてください。)
grep -l -e 'libfoo
.*deleted' /proc/*/maps |
tr -cd 0-9\\n | xargs -r ps u
OpenSSH を利用してシステムにアクセスしている場合であって、これがリンクするライブラリがアップデートされたとします。 その場合は sshd サービスの再起動が必要です。 またシステムからはいったんログアウトしてログインし直し、その後に上のコマンドをもう一度実行して、削除されたライブラリを利用していないかどうかの確認を行ってください。
systemd
デーモンが(PID 1
として実行されていて)、アップデートしたライブラリにリンクされていた場合は、リブートするのではなく、root
ユーザーになって systemctl
daemon-reexec を実行すれば再起動できます。
バイナリや共有ライブラリが上書きされると、そのバイナリや共有バイナリ内のコードやデータを利用するプロセスがクラッシュすることがあります。 プロセスがクラッシュしないように、バイナリや共有ライブラリを正しく更新する方法は、まず初めに削除を行ってから、新たなものをそこにインストールすることです。 Coreutils が提供する install コマンドは、すでにこの処理が実装されているため、たいていのパッケージにおいて、バイナリやライブラリのインストールに利用されています。 したがってそのような問題に悩まされることは、これまでほとんどなかったはずです。 しかしパッケージの中には (特に BLFS にある Mozilla JS など)、すでにあるファイルを上書きする方式をとっているため、クラッシュするものがあります。 そこでパッケージ更新の前には、それまでの作業を保存して、不要な起動プロセスは停止することが安全です。
以下に一般的なパッケージ管理手法について示します。 パッケージ管理マネージャーを用いる前に、さまざまな方法を検討し特にそれぞれの欠点も確認してください。
そうです。 これもパッケージ管理のやり方の一つです。 いろいろなパッケージに精通していて、どんなファイルがインストールされるか分かっている人もいます。 そんな人はパッケージ管理ツールを必要としません。 あるいはパッケージが更新された際にシステム全体を再構築しようと考えている人なら、やはりパッケージ管理ツールを必要としません。
これは最も単純なパッケージ管理のやり方であり、パッケージ管理のためのツールを用いる必要はありません。
個々のパッケージを個別のディレクトリにインストールする方法です。 例えば foo-1.1 というパッケージを
/usr/pkg/foo-1.1
ディレクトリにインストールし、この /usr/pkg/foo-1.1
に対するシンボリックリンク
/usr/pkg/foo
を作成します。
このパッケージの新しいバージョン foo-1.2 をインストールする際には /usr/pkg/foo-1.2
ディレクトリにインストールした上で、先ほどのシンボリックリンクをこのディレクトリを指し示すように置き換えます。
PATH
、LD_LIBRARY_PATH
、MANPATH
、INFOPATH
、CPPFLAGS
といった環境変数に対しては /usr/pkg/foo
ディレクトリを加える必要があるかもしれません。
もっともパッケージによっては、このやり方では管理できないものもあります。
これは一つ前に示したパッケージ管理テクニックの応用です。 各パッケージは同様にインストールします。
ただし先ほどのようなシンボリックリンクを生成するのではなく /usr
ディレクトリ階層の中に各ファイルのシンボリックリンクを生成します。
この方法であれば環境変数を追加設定する必要がなくなります。
シンボリックリンクを自動生成することもできますが、パッケージ管理ツールの中にはこの手法を使って構築されているものもあります。
よく知られているものとして Stow、Epkg、Graft、Depot があります。
インストール時には意図的な指示が必要です。 パッケージにとっては /usr
にインストールすることが指定されたものとなりますが、実際には
/usr/pkg
配下にインストールされるわけです。
このインストール方法は単純なものではありません。 例えば今 libfoo-1.1
というパッケージをインストールするものとします。
以下のようなコマンドでは、このパッケージを正しくインストールできません。
./configure --prefix=/usr/pkg/libfoo/1.1 make make install
インストール自体は動作しますが、このパッケージに依存している他のパッケージは期待どおりには libfoo
を正しくリンクしません。 例えば libfoo をリンクするパッケージをコンパイルする際には /usr/lib/libfoo.so.1
がリンクされると思うかもしれませんが、実際には /usr/pkg/libfoo/1.1/lib/libfoo.so.1
がリンクされることになります。 正しくリンクするためには DESTDIR
変数を使って、パッケージのインストールをうまく仕組む必要があります。
この方法は以下のようにして行います。
./configure --prefix=/usr make make DESTDIR=/usr/pkg/libfoo/1.1 install
この手法をサポートするパッケージは数多く存在しますが、そうでないものもあります。
この手法を取り入れていないパッケージに対しては、手作業でインストールすることが必要になります。
またはそういった問題を抱えるパッケージであれば /opt
ディレクトリにインストールする方が簡単かもしれません。
この方法ではパッケージをインストールするにあたって、あるファイルにタイムスタンプが記されます。 インストールの直後に find コマンドを適当なオプション指定により用いることで、インストールされるすべてのファイルのログが生成されます。 これはタイムスタンプファイルの生成の後に行われます。 この方法を用いたパッケージ管理ツールとして install-log があります。
この方法はシンプルであるという利点がありますが、以下の二つの欠点があります。 インストールの際に、いずれかのファイルのタイムスタンプが現在時刻でなかった場合、そういったファイルはパッケージ管理ツールが正しく制御できません。 またこの方法は一つのパッケージだけが、その時にインストールされることを前提とします。 例えば二つのパッケージが二つの異なる端末から同時にインストールされるような場合は、ログファイルが適切に生成されません。
この方法はインストールスクリプトが実行するコマンドを記録するものです。 これには以下の二種類の手法があります。
インストールされるライブラリを事前にロードする場所を環境変数 LD_PRELOAD
に定めておいてそれからインストールを行う方法です。
パッケージのインストール中には cp、install、mv
など、さまざまな実行モジュールにそのライブラリをリンクさせ、ファイルシステムを変更するようなシステムコールを監視することで、そのライブラリがパッケージを追跡管理できるようにします。
この方法を実現するためには、動的リンクする実行モジュールはすべて suid ビット、sgid
ビットがオフでなければなりません。
事前にライブラリをロードしておくと、インストール中に予期しない副作用が発生するかもしれません。
したがって、ある程度のテスト確認を行って、パッケージ管理ツールが不具合を引き起こさないこと、しかるべきファイルの記録を取っておくことが必要とされます。
二つめの方法は strace を用いるものです。 これはインストールスクリプトの実行中に発生するシステムコールを記録するものです。
この方法では、シンボリックリンク方式によるパッケージ管理にて説明したのと同じように、パッケージが個別のディレクトリにインストールされます。 インストールの後は、インストールされたファイルのアーカイブが生成されます。 このアーカイブはローカルPCへのインストールに用いられたり、他のPCへのインストールに利用されたりします。
商用ディストリビューションが採用しているパッケージ管理ツールは、ほとんどがこの方法によるものです。 この方法に従ったパッケージ管理ツールの例に RPM があります。 (これは Linux Standard Base Specification が規定しています。) また pkg-utils、Debian の apt、Gentoo の Portage システムがあります。 このパッケージ管理手法を LFS システムに適用するヒント情報が https://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt にあります。
パッケージファイルにその依存パッケージ情報まで含めてアーカイブ生成することは、非常に複雑となり LFS の範疇を超えるものです。
Slackware は、パッケージアーカイブに対して tar ベースのシステムを利用しています。 他のパッケージ管理ツールはパッケージの依存性を取り扱いますが、このシステムは意図的にこれを行っていません。 Slackware のパッケージ管理に関する詳細は http://www.slackbook.org/html/package-management.html を参照してください。
この手法は LFS に固有のものであり Matthias Benkmann により考案されました。 ヒントプロジェクト (Hints Project) から入手することが出来ます。 考え方としては、各パッケージを個々のユーザーが共有ディレクトリにインストールします。 パッケージに属するファイル類は、ユーザーIDを確認することで容易に特定出来るようになります。 この手法の特徴や短所については、複雑な話となるため本節では説明しません。 詳しくは https://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt に示されているヒントを参照してください。
LFS システムの利点の一つとして、どのファイルもディスク上のどこに位置していても構わないことです。
他のコンピューターに対してビルドした LFS
の複製を作ろうとするなら、それが同等のアーキテクチャーであれば容易に実現できます。 つまり tar コマンドを使って LFS
のルートディレクトリを含むパーティション (LFS の基本的なビルドの場合、非圧縮で 250MB 程度)
をまとめ、これをネットワーク転送か、あるいは CD-ROM を通じて新しいシステムにコピーし、伸張 (解凍)
するだけです。 この場合でも、設定ファイルはいくらか変更することが必要です。
変更が必要となる設定ファイルは以下のとおりです。 /etc/hosts
, /etc/fstab
, /etc/passwd
, /etc/group
, /etc/shadow
,
/etc/ld.so.conf
新しいシステムのハードウェアと元のカーネルに差異があるかもしれないため、カーネルを再ビルドする必要があるでしょう。
類似するアーキテクチャーのシステム間にてコピーを行う際には問題が生じるとの報告があります。 例えばインテルアーキテクチャーに対する命令セットは AMD プロセッサーに対するものと完全に一致しているわけではないため、一方の命令セットが後に他方で動作しなくなることも考えられます。
最後に新システムを起動可能とするために 「GRUB を用いたブートプロセスの設定」を設定する必要があります。
Man-pages パッケージは 2,200 以上のマニュアルページを提供します。
Man-pages をインストールするために以下を実行します。
make prefix=/usr install
Iana-Etc パッケージはネットワークサービスやプロトコルのためのデータを提供します。
このパッケージでは、必要とするファイルを所定の場所にコピーするだけにします。
cp services protocols /etc
Glibc パッケージは主要な C ライブラリを提供します。 このライブラリは基本的な処理ルーチンを含むもので、メモリ割り当て、ディレクトリ走査、ファイルのオープン、クローズや入出力、文字列操作、パターンマッチング、算術処理、等々があります。
Glibc のプログラムの中には /var/db
ディレクトリに実行データを収容するものがあり、これは FHS に準拠していません。
以下のパッチを適用することで、実行データの収容先を FHS 準拠のディレクトリとします。
patch -Np1 -i ../glibc-2.36-fhs-1.patch
Glibc のドキュメントでは専用のビルドディレクトリを作成することが推奨されています。
mkdir -v build cd build
ldconfig と
sln ユーティリティーを
/usr/sbin
にインストールするようにします。
echo "rootsbindir=/usr/sbin" > configparms
Glibc をコンパイルするための準備をします。
../configure --prefix=/usr \ --disable-werror \ --enable-kernel=3.2 \ --enable-stack-protector=strong \ --with-headers=/usr/include \ libc_cv_slibdir=/usr/lib
configure オプションの意味
--disable-werror
GCC に対して -Werror オプションを利用しないようにします。 テストスイートを実行するために必要となります。
--enable-kernel=3.2
本オプションはビルドシステムに対して、カーネルバージョンが古くても 3.2 を用いることを指示します。 これより古いバージョンにおけるシステムコールが用いられないようにするため、その回避策をとるものです。
--enable-stack-protector=strong
このオプション指定によりスタックに積まれる関数プリアンブル内に、追加のコードを付与することにより、システムセキュリティを向上させます。 その追加コードは、スタック破壊攻撃(stack smashing attacks)のようなバッファーオーバーフローをチェックします。
--with-headers=/usr/include
このオプションはビルドシステムにおいて、カーネル API ヘッダーを探す場所を指定します。
libc_cv_slibdir=/usr/lib
この変数によって、あらゆるシステムにおけるライブラリを正しく設定します。 lib64 は利用しません。
パッケージをコンパイルします。
make
本節における Glibc のテストスイートは極めて重要なものです。 したがってどのような場合であっても必ず実行してください。
全般にテストの中には失敗するものがありますが、以下に示すものであれば無視しても構いません。
make check
テストに失敗する場合があります。 これは Glibc のテストスイートがホストシステムにある程度依存しているためです。 4200 を超えるテストの中で、ほんの少数のテストは失敗しますが、無視できるものです。 LFS の当バージョンにおいて発生しがちな問題を以下に示します。
io/tst-lchmod は LFS の chroot 環境においては失敗します。
misc/tst-ttyname は LFS の chroot 環境においては失敗します。
nss/tst-nss-files-hosts-long は失敗することがあります。 これはシステム内にループバック以外の IP アドレスがない場合です。
ホストのカーネルが比較的古い場合に stdlib/tst-arc4random-thread というテストが失敗します。
nss/tst-nss-files-hosts-multi のようなテストでは、内部のタイムアウトが原因で比較的遅くなるシステム上では失敗します。
支障が出る話ではありませんが Glibc のインストール時には /etc/ld.so.conf
ファイルが存在していないとして警告メッセージが出力されます。 これをなくすために以下を実行します。
touch /etc/ld.so.conf
Makefile を修正して、不要な健全性チェックを無効にします。 これは、この段階での LFS 環境では失敗するためです。
sed '/test-installation/s@$(PERL)@echo not running@' -i ../Makefile
パッケージをインストールします。
make install
ldd スクリプト内にある実行可能なローダーへのパスがハードコーディングされているので、これを修正します。
sed '/RTLDLIST=/s@/usr@@g' -i /usr/bin/ldd
nscd コマンドに対する設定ファイルや実行ディレクトリをインストールします。
cp -v ../nscd/nscd.conf /etc/nscd.conf mkdir -pv /var/cache/nscd
nscd コマンドに対しての systemd サポートファイルをインストールします。
install -v -Dm644 ../nscd/nscd.tmpfiles /usr/lib/tmpfiles.d/nscd.conf install -v -Dm644 ../nscd/nscd.service /usr/lib/systemd/system/nscd.service
システムを各種の言語に対応させるためのロケールをインストールします。 テストスイートにおいてロケールは必要ではありませんが、将来的にはロケールが不足していることによって、重要なテストが実施されずに見逃してしまうかもしれません。
各ロケールは localedef
プログラムを使ってインストールします。 例えば以下に示す 2 つめの localedef
では、キャラクターセットには依存しないロケール定義 /usr/share/i18n/locales/cs_CZ
とキャラクターマップ定義
/usr/share/i18n/charmaps/UTF-8.gz
とを結合させて
/usr/lib/locale/locale-archive
ファイルにその情報を付け加えます。
以下のコマンドは、テストを成功させるために必要となる最低限のロケールをインストールするものです。
mkdir -pv /usr/lib/locale localedef -i POSIX -f UTF-8 C.UTF-8 2> /dev/null || true localedef -i cs_CZ -f UTF-8 cs_CZ.UTF-8 localedef -i de_DE -f ISO-8859-1 de_DE localedef -i de_DE@euro -f ISO-8859-15 de_DE@euro localedef -i de_DE -f UTF-8 de_DE.UTF-8 localedef -i el_GR -f ISO-8859-7 el_GR localedef -i en_GB -f ISO-8859-1 en_GB localedef -i en_GB -f UTF-8 en_GB.UTF-8 localedef -i en_HK -f ISO-8859-1 en_HK localedef -i en_PH -f ISO-8859-1 en_PH localedef -i en_US -f ISO-8859-1 en_US localedef -i en_US -f UTF-8 en_US.UTF-8 localedef -i es_ES -f ISO-8859-15 es_ES@euro localedef -i es_MX -f ISO-8859-1 es_MX localedef -i fa_IR -f UTF-8 fa_IR localedef -i fr_FR -f ISO-8859-1 fr_FR localedef -i fr_FR@euro -f ISO-8859-15 fr_FR@euro localedef -i fr_FR -f UTF-8 fr_FR.UTF-8 localedef -i is_IS -f ISO-8859-1 is_IS localedef -i is_IS -f UTF-8 is_IS.UTF-8 localedef -i it_IT -f ISO-8859-1 it_IT localedef -i it_IT -f ISO-8859-15 it_IT@euro localedef -i it_IT -f UTF-8 it_IT.UTF-8 localedef -i ja_JP -f EUC-JP ja_JP localedef -i ja_JP -f SHIFT_JIS ja_JP.SJIS 2> /dev/null || true localedef -i ja_JP -f UTF-8 ja_JP.UTF-8 localedef -i nl_NL@euro -f ISO-8859-15 nl_NL@euro localedef -i ru_RU -f KOI8-R ru_RU.KOI8-R localedef -i ru_RU -f UTF-8 ru_RU.UTF-8 localedef -i se_NO -f UTF-8 se_NO.UTF-8 localedef -i ta_IN -f UTF-8 ta_IN.UTF-8 localedef -i tr_TR -f UTF-8 tr_TR.UTF-8 localedef -i zh_CN -f GB18030 zh_CN.GB18030 localedef -i zh_HK -f BIG5-HKSCS zh_HK.BIG5-HKSCS localedef -i zh_TW -f UTF-8 zh_TW.UTF-8
上に加えて、あなたの国、言語、キャラクターセットを定めるためのロケールをインストールしてください。
必要に応じて glibc-2.36/localedata/SUPPORTED
に示されるすべてのロケールを同時にインストールしてください。(そこには上のロケールも含め、すべてのロケールが列記されています。)
以下のコマンドによりそれを実現します。 ただしこれには相当な処理時間を要します。
make localedata/install-locales
さらに必要なら glibc-2.36/localedata/SUPPORTED
ファイルに示されていないロケールは localedef
コマンドを使って生成、インストールを行ってください。 たとえば以下の 2
つのロケールは、本章で後に実施するテストにおいて必要になります。
localedef -i POSIX -f UTF-8 C.UTF-8 2> /dev/null || true localedef -i ja_JP -f SHIFT_JIS ja_JP.SJIS 2> /dev/null || true
現状の Glibc は、国際ドメイン名の解決に libidn2 を利用します。 これは実行時に依存するパッケージです。 この機能が必要である場合は、BLFS にある libidn2 ページに示されているインストール手順を参照してください。
/etc/nsswitch.conf
ファイルを作成しておく必要があります。 このファイルが無い場合、Glibc のデフォルト値ではネットワーク環境下にて
Glibc が正しく動作しません。
以下のコマンドを実行して /etc/nsswitch.conf
ファイルを生成します。
cat > /etc/nsswitch.conf << "EOF"
# Begin /etc/nsswitch.conf
passwd: files
group: files
shadow: files
hosts: files dns
networks: files
protocols: files
services: files
ethers: files
rpc: files
# End /etc/nsswitch.conf
EOF
以下によりタイムゾーンデータをインストールし設定します。
tar -xf ../../tzdata2022c.tar.gz ZONEINFO=/usr/share/zoneinfo mkdir -pv $ZONEINFO/{posix,right} for tz in etcetera southamerica northamerica europe africa antarctica \ asia australasia backward; do zic -L /dev/null -d $ZONEINFO ${tz} zic -L /dev/null -d $ZONEINFO/posix ${tz} zic -L leapseconds -d $ZONEINFO/right ${tz} done cp -v zone.tab zone1970.tab iso3166.tab $ZONEINFO zic -d $ZONEINFO -p America/New_York unset ZONEINFO
zic コマンドの意味
zic -L
/dev/null ...
うるう秒を含まない posix タイムゾーンデータを生成します。 これらは zoneinfo
や zoneinfo/posix
に収容するものとして適切なものです。
zoneinfo
へは POSIX
準拠のタイムゾーンデータを含めることが必要であり、こうしておかないと数々のテストスイートにてエラーが発生してしまいます。
組み込みシステムなどでは容量の制約が厳しいため、タイムゾーンデータはあまり更新したくない場合があり、posix
ディレクトリを設けなければ 1.9 MB もの容量を節約できます。
ただしアプリケーションやテストスイートによっては、エラーが発生するかもしれません。
zic -L
leapseconds ...
うるう秒を含んだ正しいタイムゾーンデータを生成します。
組み込みシステムなどでは容量の制約が厳しいため、タイムゾーンデータはあまり更新したくない場合や、さほど気にかけない場合もあります。
right
ディレクトリを省略することにすれば
1.9MB の容量を節約することができます。
zic ...
-p ...
posixrules
ファイルを生成します。
ここでは New York を用います。 POSIX では、日中の保存時刻として US
ルールに従うことを規程しているためです。
ローカルなタイムゾーンの設定を行う1つの方法として、ここでは以下のスクリプトを実行します。
tzselect
地域情報を設定するためにいくつか尋ねられるのでそれに答えます。 このスクリプトはタイムゾーン名を表示します。(例えば
America/Edmonton
などです。) /usr/share/zoneinfo
ディレクトリにはさらに Canada/Eastern や EST5EDT のようなタイムゾーンもあります。
これらはこのスクリプトでは認識されませんが、利用することは可能です。
以下のコマンドにより /etc/localtime
ファイルを生成します。
ln -sfv /usr/share/zoneinfo/<xxx>
/etc/localtime
<xxx>
の部分は設定するタイムゾーンの名前 (例えば Canada/Eastern など) に置き換えてください。
ダイナミックリンカー (/lib/ld-linux.so.2
)
がダイナミックライブラリを検索するデフォルトのディレクトリが /usr/lib
ディレクトリです。
各種プログラムが実行される際にはここから検索されたダイナミックライブラリがリンクされます。 もし
/usr/lib
以外のディレクトリにライブラリファイルがあるなら /etc/ld.so.conf
ファイルに記述を追加して、ダイナミックローダーがそれらを探し出せるようにしておくことが必要です。
追加のライブラリが配置されるディレクトリとしては /usr/local/lib
ディレクトリと /opt/lib
ディレクトリという二つがよく利用されます。
ダイナミックローダーの検索パスとして、それらのディレクトリを追加します。
以下のコマンドを実行して /etc/ld.so.conf
ファイルを新たに生成します。
cat > /etc/ld.so.conf << "EOF"
# Begin /etc/ld.so.conf
/usr/local/lib
/opt/lib
EOF
必要がある場合には、ダイナミックローダーに対する設定として、他ディレクトリにて指定されるファイルをインクルードするようにもできます。 通常は、そのファイル内の1行に、必要となるライブラリパスを記述します。 このような設定を利用する場合には以下のようなコマンドを実行します。
cat >> /etc/ld.so.conf << "EOF"
# Add an include directory
include /etc/ld.so.conf.d/*.conf
EOF
mkdir -pv /etc/ld.so.conf.d
メッセージカタログを生成します。 |
|
ファイルシステムに固有の変数に設定された値を表示します。 |
|
管理データベースから設定項目を取得します。 |
|
キャラクターセットを変換します。 |
|
高速ロードができる iconv モジュール設定ファイルを生成します。 |
|
ダイナミックリンカーの実行時バインディングを設定します。 |
|
指定したプログラムまたは共有ライブラリが必要としている共有ライブラリを表示します。 |
|
オブジェクトファイルを使って ldd コマンドを補助します。 これは x86_64 のような最新アーキテクチャーには存在しません。 |
|
現在のロケールに対するさまざまな情報を表示します。 |
|
ロケールの設定をコンパイルします。 |
|
テキストを入力として単純なデータベースを生成します。 |
|
メモリトレースファイル (memory trace file) を読み込んで解釈します。 そして可読可能な書式で出力します。 |
|
一般的なネームサービスへの変更要求のキャッシュを提供するデーモン。 |
|
PC プロファイリングによって生成された情報をダンプします。 |
|
稼動中のプロセスにて利用されている動的共有オブジェクト (dynamic shared objects) を一覧出力します。 |
|
スタティックなリンクを行う ln プログラム。 |
|
指定されたコマンドの共有ライブラリ内のプロシジャーコールをトレースします。 |
|
共有オブジェクトのプロファイリングデータを読み込んで表示します。 |
|
ユーザーに対してシステムの設置地域を問合せ、対応するタイムゾーンの記述を表示します。 |
|
プログラム内にて現在実行されている関数を表示することで、そのプログラムの実行状況を追跡します。 |
|
タイムゾーンをダンプします。 |
|
タイムゾーンコンパイラー。 |
|
共有ライブラリのためのヘルパープログラム。 |
|
Glibc が内部で利用するもので、異常が発生しているプログラムを見つけ出します。(例えば Motif
アプリケーションなど) 詳しくは |
|
非同期の名前解決 (asynchronous name lookup) ライブラリ。 |
|
主要な C ライブラリ。 |
|
プリロード時のメモリ割り当てチェックをオンにします。 |
|
暗号化ライブラリ。 |
|
何の関数も含まないダミーライブラリ。
以前はダイナミックリンクインターフェースライブラリでしたが、現在その関数は |
|
何の関数も含まないダミーのライブラリ。 かつては g++ のランタイムライブラリであったものです。 |
|
数学ライブラリ。 |
|
ベクトル数学ライブラリ。 |
|
このライブラリにリンクした場合、メモリ割り当てのチェック機能を有効にします。 |
|
memusage コマンドが利用するもので、プログラムのメモリ使用に関する情報を収集します。 |
|
ネットワークサービスライブラリ。 現在は非推奨。 |
|
NSS (Name Service Switch) モジュール。
ホスト、ユーザー名、エイリアス、サービス、プロトコルなどの名前解決を行う関数を提供します。
|
|
PC プロファイルにたいして実行モジュールをプリロードするために用いられます。 |
|
関数を全く含まないダミーのライブラリ。 かつては POSIX.1b Realtime
Extension によって規定されているインターフェースをほとんど含めた関数を提供していました。
現在その関数は |
|
インターネットドメインネームサーバーに対しての、パケットの生成、送信、解析を行う関数を提供します。 |
|
POSIX.1b リアルタイム拡張 (Realtime Extension) にて既定されているインターフェースをほぼ網羅した関数を提供します。 |
|
マルチスレッドプログラム用のデバッガーを構築するための有用な関数を提供します。 |
|
何の関数も含まないダミーライブラリ。 以前は、 さまざまな Unix
ユーティリティーに用いられる「標準的な」関数のコードを含んでいました。 現在その関数は
|
Zlib パッケージは、各種プログラムから呼び出される、圧縮、伸張 (解凍) を行う関数を提供します。
Zlib をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルします。
make
コンパイル結果をテストするには以下を実行します。
make check
パッケージをインストールします。
make install
不要なスタティックライブラリを削除します。
rm -fv /usr/lib/libz.a
Bzip2 パッケージはファイル圧縮、伸長 (解凍) を行うプログラムを提供します。 テキストファイルであれば、これまでよく用いられてきた gzip に比べて bzip2 の方が圧縮率の高いファイルを生成できます。
本パッケージのドキュメントをインストールするためにパッチを適用します。
patch -Np1 -i ../bzip2-1.0.8-install_docs-1.patch
以下のコマンドによりシンボリックリンクを相対的なものとしてインストールします。
sed -i 's@\(ln -s -f \)$(PREFIX)/bin/@\1@' Makefile
man ページのインストール先を正しいディレクトリに修正します。
sed -i "s@(PREFIX)/man@(PREFIX)/share/man@g" Makefile
Bzip2 をコンパイルするための準備をします。
make -f Makefile-libbz2_so make clean
make パラメーターの意味
-f
Makefile-libbz2_so
このパラメーターは Bzip2 のビルドにあたって通常の Makefile
ファイルではなく Makefile-libbz2_so
ファイルを利用することを指示します。
これはダイナミックライブラリ libbz2.so
をビルドし Bzip2 の各種プログラムをこれにリンクします。
パッケージのコンパイルとテストを行います。
make
パッケージをインストールします。
make PREFIX=/usr install
共有ライブラリをインストールします。
cp -av libbz2.so.* /usr/lib ln -sv libbz2.so.1.0.8 /usr/lib/libbz2.so
共有化された bzip2
実行モジュールを /usr/bin
ディレクトリにインストールします。 またシンボリックリンクにより bzip2 のコピーを 2 つ作ります。
cp -v bzip2-shared /usr/bin/bzip2 for i in /usr/bin/{bzcat,bunzip2}; do ln -sfv bzip2 $i done
不要なスタティックライブラリを削除します。
rm -fv /usr/lib/libbz2.a
bzip2 で圧縮されたファイルを解凍します。 |
|
解凍結果を標準出力に出力します。 |
|
bzip2 で圧縮されたファイルに対して cmp を実行します。 |
|
bzip2 で圧縮されたファイルに対して diff を実行します。 |
|
bzip2 で圧縮されたファイルに対して egrep を実行します。 |
|
bzip2 で圧縮されたファイルに対して fgrep を実行します。 |
|
bzip2 で圧縮されたファイルに対して grep を実行します。 |
|
ブロックソート法 (バロウズ-ホイラー変換) とハフマン符号化法を用いてファイル圧縮を行います。 圧縮率は、従来用いられてきた「Lempel-Ziv」アルゴリズムによるもの、例えば gzip コマンドによるものに比べて高いものです。 |
|
壊れた bzip2 ファイルの復旧を試みます。 |
|
bzip2 で圧縮されたファイルに対して less を実行します。 |
|
bzip2 で圧縮されたファイルに対して more を実行します。 |
|
ブロックソート法 (バロウズ-ホイラー変換) による可逆的なデータ圧縮を提供するライブラリ。 |
Xz パッケージは、ファイルの圧縮、伸張 (解凍) を行うプログラムを提供します。 これは lzma フォーマットおよび新しい xz 圧縮フォーマットを取り扱います。 xz コマンドによりテキストファイルを圧縮すると、従来の gzip コマンドや bzip2 コマンドに比べて、高い圧縮率を実現できます。
Xz をコンパイルするための準備をします。
./configure --prefix=/usr \ --disable-static \ --docdir=/usr/share/doc/xz-5.2.6
パッケージをコンパイルします。
make
ビルド結果をテストする場合は以下を実行します。
make check
パッケージをインストールします。
make install
ファイルを伸張 (解凍) し標準出力へ出力します。 |
|
LZMA 圧縮されたファイルに対して cmp を実行します。 |
|
LZMA 圧縮されたファイルに対して diff を実行します。 |
|
LZMA 圧縮されたファイルに対して egrep を実行します。 |
|
LZMA 圧縮されたファイルに対して fgrep を実行します。 |
|
LZMA 圧縮されたファイルに対して grep を実行します。 |
|
LZMA 圧縮されたファイルに対して less を実行します。 |
|
LZMA フォーマットによりファイルの圧縮と伸張 (解凍) を行います。 |
|
LZMA 圧縮されたファイルを高速に伸張 (解凍) するコンパクトなプログラムです。 |
|
LZMA 圧縮されたファイルのヘッダーに保持されている情報を表示します。 |
|
LZMA 圧縮されたファイルに対して more を実行します。 |
|
LZMA フォーマットされたファイルを伸張 (解凍) します。 |
|
XZ フォーマットされたファイルを伸張 (解凍) します。 |
|
XZ フォーマットによりファイルの圧縮と伸張 (解凍) を行います。 |
|
ファイルの伸張 (解凍) を行い標準出力へ出力します。 |
|
XZ 圧縮されたファイルに対して cmp を実行します。 |
|
XZ 圧縮されたファイルを高速に伸張 (解凍) するコンパクトなプログラムです。 |
|
XZ 圧縮されたファイルに対して diff を実行します。 |
|
XZ 圧縮されたファイルに対して egrep を実行します。 |
|
XZ 圧縮されたファイルに対して fgrep を実行します。 |
|
XZ 圧縮されたファイルに対して grep を実行します。 |
|
XZ 圧縮されたファイルに対して less を実行します。 |
|
XZ 圧縮されたファイルに対して more を実行します。 |
|
Lempel-Ziv-Markov のチェーンアルゴリズムを利用し、損失なくブロックソートによりデータ圧縮を行う機能を提供するライブラリです。 |
Zstandard とはリアルタイムの圧縮アルゴリズムのことであり、高圧縮率を実現します。 圧縮、処理速度間のトレードオフを広範囲に提供するとともに、高速な伸張(解凍)処理を実現します。
アップストリームが認識している問題修正のためのパッチを適用します。
patch -Np1 -i ../zstd-1.5.2-upstream_fixes-1.patch
パッケージをコンパイルします。
make prefix=/usr
テスト結果の出力の中に 'failed' と示される箇所があります。 これは実際のテストが失敗したときだけ 'FAIL' と出力されるものです。 したがってテスト失敗ではありません。
ビルド結果をテストするには以下を実行します。
make check
パッケージをインストールします。
make prefix=/usr install
スタティックライブラリを削除します。
rm -v /usr/lib/libzstd.a
File パッケージは指定されたファイルの種類を決定するユーティリティを提供します。
File をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルします。
make
コンパイル結果をテストするには以下を実行します。
make check
パッケージをインストールします。
make install
Readline パッケージはコマンドラインの編集や履歴管理を行うライブラリを提供します。
Readline を再インストールすると、それまでの古いライブラリは <ライブラリ名>.old というファイル名でコピーされます。 これは普通は問題ないことですが ldconfig によるリンクに際してエラーを引き起こすことがあります。 これを避けるため以下の二つの sed コマンドを実行します。
sed -i '/MV.*old/d' Makefile.in sed -i '/{OLDSUFF}/c:' support/shlib-install
Readline をコンパイルするための準備をします。
./configure --prefix=/usr \ --disable-static \ --with-curses \ --docdir=/usr/share/doc/readline-8.1.2
configure オプションの意味
--with-curses
このオプションは Readline パッケージに対して、termcap
ライブラリ関数の探し場所を、切り離されている termcap ライブラリではなく curses
ライブラリとすることを指示します。 これにより readline.pc
ファイルが適切に生成されます。
パッケージをコンパイルします。
make SHLIB_LIBS="-lncursesw"
make オプションの意味
SHLIB_LIBS="-lncursesw"
このオプションにより Readline を libncursesw
ライブラリにリンクします。
このパッケージにテストスイートはありません。
パッケージをインストールします。
make SHLIB_LIBS="-lncursesw" install
必要ならドキュメントをインストールします。
install -v -m644 doc/*.{ps,pdf,html,dvi} /usr/share/doc/readline-8.1.2
M4 パッケージはマクロプロセッサーを提供します。
M4 をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルします。
make
ビルド結果をテストする場合は以下を実行します。
make check
パッケージをインストールします。
make install
Bc パッケージは、任意精度 (arbitrary precision) の演算処理言語を提供します。
Bc をコンパイルするための準備をします。
CC=gcc ./configure --prefix=/usr -G -O3 -r
configure オプションの意味
CC=gcc
このパラメーターはコンパイラーを指定します。
-G
GNU bc が存在していない状態では動作しないテストスイートを省略します。
-O3
利用する最適化を指定します。
-r
bc における行編集機能を拡張するために Readline 利用を有効にします。
パッケージをコンパイルします。
make
ビルド結果をテストする場合は、以下を実行します。
make test
パッケージをインストールします。
make install
Flex パッケージは、字句パターンを認識するプログラムを生成するユーティリティを提供します。
Flex をコンパイルするための準備をします。
./configure --prefix=/usr \ --docdir=/usr/share/doc/flex-2.6.4 \ --disable-static
パッケージをコンパイルします。
make
コンパイル結果をテストするために以下を実行します。(約 0.5 SBU)
make check
パッケージをインストールします。
make install
プログラムの中には flex
コマンドが用いられず、その前身である lex コマンドを実行しようとするものがあります。
そういったプログラムへ対応するために lex
という名のシンボリックリンクを生成します。 このリンクが lex
のエミュレーションモードとして flex
を呼び出します。
ln -sv flex /usr/bin/lex
Tcl パッケージは、堅牢で汎用的なスクリプト言語であるツールコマンド言語 (Tool Command Language) を提供します。 Expect パッケージは Tcl 言語によって書かれています。
本パッケージとこれに続く 2 つのパッケージ (Expect と DejaGNU) は、Binutils および GCC などにおけるテストスイートを実行するのに必要となるためインストールするものです。 テスト目的のためにこれら 3 つのパッケージをインストールするというのは、少々大げさなことかもしれません。 ただ本質的ではないことであっても、重要なツール類が正常に動作するという確認が得られれば安心できます。
はじめにドキュメントを伸張(解凍)する以下のコマンドを実行します。
tar -xf ../tcl8.6.12-html.tar.gz --strip-components=1
Tcl をコンパイルするための準備をします。
SRCDIR=$(pwd) cd unix ./configure --prefix=/usr \ --mandir=/usr/share/man
パッケージをビルドします。
make sed -e "s|$SRCDIR/unix|/usr/lib|" \ -e "s|$SRCDIR|/usr/include|" \ -i tclConfig.sh sed -e "s|$SRCDIR/unix/pkgs/tdbc1.1.3|/usr/lib/tdbc1.1.3|" \ -e "s|$SRCDIR/pkgs/tdbc1.1.3/generic|/usr/include|" \ -e "s|$SRCDIR/pkgs/tdbc1.1.3/library|/usr/lib/tcl8.6|" \ -e "s|$SRCDIR/pkgs/tdbc1.1.3|/usr/include|" \ -i pkgs/tdbc1.1.3/tdbcConfig.sh sed -e "s|$SRCDIR/unix/pkgs/itcl4.2.2|/usr/lib/itcl4.2.2|" \ -e "s|$SRCDIR/pkgs/itcl4.2.2/generic|/usr/include|" \ -e "s|$SRCDIR/pkgs/itcl4.2.2|/usr/include|" \ -i pkgs/itcl4.2.2/itclConfig.sh unset SRCDIR
"make" コマンドに続くたくさんの "sed" コマンドは、設定ファイルにあるビルドディレクトリへの参照を削除して、インストールディレクトリへの参照に置き換えます。 これ以降の LFS 作業において必須のことではありませんが、後にビルドされるパッケージが Tcl を用いるかもしれないからです。
ビルド結果をテストする場合は、以下を実行します。
make test
パッケージをインストールします。
make install
インストールされたライブラリを書き込み可能にします。 こうすることで後にデバッグシンボルを削除できるようにします。
chmod -v u+w /usr/lib/libtcl8.6.so
Tcl のヘッダーファイルをインストールします。 これらは次にビルドする Expect が必要とするファイルです。
make install-private-headers
必要となるシンボリックリンクを生成します。
ln -sfv tclsh8.6 /usr/bin/tclsh
Perl の man ページと重複するものを名称変更します。
mv /usr/share/man/man3/{Thread,Tcl_Thread}.3
任意のドキュメントをダウンロードしている場合は、 以下のコマンドを実行してインストールします。
mkdir -v -p /usr/share/doc/tcl-8.6.12 cp -v -r ../html/* /usr/share/doc/tcl-8.6.12
Expect パッケージには telnet, ftp, passwd, fsck, rlogin, tip といった対話処理ツールを、スクリプト化されたダイアログを通じて自動化するツールを提供します。 Expect はこういったアプリケーションをテストする場合にも利用できます。 また本パッケージを利用しないと相当に困難となるようなタスクを、いとも簡単に処理できるようになります。 DejaGnu フレームワークはこの Expect を用いて記述されています。
Expect をコンパイルするための準備をします。
./configure --prefix=/usr \ --with-tcl=/usr/lib \ --enable-shared \ --mandir=/usr/share/man \ --with-tclinclude=/usr/include
configure オプションの意味
--with-tcl=/usr/lib
本パラメーターは configure に対して、tclConfig.sh スクリプトが存在するディレクトリを指示するために必要となります。
--with-tclinclude=/usr/include
Tcl の内部ヘッダーファイルを探し出す場所を指定します。
パッケージをビルドします。
make
ビルド結果をテストする場合は、以下を実行します。
make test
パッケージをインストールします。
make install ln -svf expect5.45.4/libexpect5.45.4.so /usr/lib
DejaGnu パッケージは、GNU ツールに対してテストスイートを実行するフレームワークを提供します。 これは expect によって書かれており、expect そのものは Tcl(ツールコマンド言語)を利用しています。
アップストリームは、専用のビルドディレクトリを作成して DejaGNU をビルドすることを推奨しています。
mkdir -v build cd build
DejaGNU をコンパイルするための準備をします。
../configure --prefix=/usr makeinfo --html --no-split -o doc/dejagnu.html ../doc/dejagnu.texi makeinfo --plaintext -o doc/dejagnu.txt ../doc/dejagnu.texi
パッケージをビルドしてインストールします。
make install install -v -dm755 /usr/share/doc/dejagnu-1.6.3 install -v -m644 doc/dejagnu.{html,txt} /usr/share/doc/dejagnu-1.6.3
コンパイル結果をテストするなら以下を実行します。
make check
Binutils パッケージは、リンカーやアセンブラーなどのようにオブジェクトファイルを取り扱うツール類を提供します。
PTY が chroot 環境内にて正しく作動しているかどうかを確認するために、以下の簡単なテストを実行します。
expect -c "spawn ls"
上のコマンドは以下を出力するはずです。
spawn ls
上のような出力ではなく、以下のような出力メッセージが含まれていたら、PTY の動作が適切に構築できていないことを示しています。 Binutils や GCC のテストスイートを実行する前に、この症状は解消しておく必要があります。
The system has no more ptys.
Ask your system administrator to create more.
Binutils のドキュメントによると Binutils のビルドにあたっては専用のビルドディレクトリを作成することが推奨されています。
mkdir -v build cd build
Binutils をコンパイルするための準備をします。
../configure --prefix=/usr \ --sysconfdir=/etc \ --enable-gold \ --enable-ld=default \ --enable-plugins \ --enable-shared \ --disable-werror \ --enable-64-bit-bfd \ --with-system-zlib
configure パラメーターの意味
--enable-gold
ゴールドリンカー (gold linker) をビルドし ld.gold としてインストールします。
--enable-ld=default
オリジナルの bfd リンカーをビルドし ld (デフォルトリンカー) と ld.bfd としてインストールします。
--enable-plugins
リンカーに対してプラグインサポートを有効にします。
--enable-64-bit-bfd
64 ビットサポート(ホスト上でのワードサイズの縮小)を有効にします。 64 ビットシステムでも不要な場合がありますが、指定しておいて支障はありません。
--with-system-zlib
本パッケージに含まれる zlib をビルドするのではなく、既にインストール済の zlib を用いるようにします。
パッケージをコンパイルします。
make tooldir=/usr
make パラメーターの意味
tooldir=/usr
通常 tooldir (実行ファイルが最終的に配置されるディレクトリ) は $(exec_prefix)/$(target_alias)
に設定されています。 x86_64 マシンでは /usr/x86_64-pc-linux-gnu
となります。 LFS
は自分で設定を定めていくシステムですから /usr
ディレクトリ配下に CPU ターゲットを特定するディレクトリを設ける必要がありません。
$(exec_prefix)/$(target_alias)
というディレクトリ構成は、クロスコンパイル環境において必要となるものです。
(例えばパッケージをコンパイルするマシンが Intel であり、そこから PowerPC
マシン用の実行コードを生成するような場合です。)
本節における Binutils のテストスイートは極めて重要なものです。 したがってどのような場合であっても必ず実行してください。
コンパイル結果をテストします。
make -k check
パッケージをインストールします。
make tooldir=/usr install
不要なスタティックライブラリを削除します。
rm -fv /usr/lib/lib{bfd,ctf,ctf-nobfd,opcodes}.a
指定された実行モジュール名とアドレスに基づいて、プログラム内のアドレスをファイル名と行番号に変換します。 これは実行モジュール内のデバッグ情報を利用します。 特定のアドレスがどのソースファイルと行番号に該当するかを確認するものです。 |
|
アーカイブの生成、修正、抽出を行います。 |
|
gcc の出力結果をアセンブルして、オブジェクトファイルとして生成するアセンブラー。 |
|
リンカーから呼び出されるもので C++ と Java のシンボルを複合 (demangle) し、オーバーロード関数が破壊されることを回避します。 |
|
DWARF パッケージユーティリティー。 |
|
ELF ファイルの ELF ヘッダーを更新します。 |
|
コールグラフ (call graph) のプロファイルデータを表示します。 |
|
性能データの収集と解析を行います。 |
|
複数のオブジェクトファイルやアーカイブファイルから、一つのファイルを生成するリンカー。 データの再配置やシンボル参照情報の結合を行います。 |
|
elf オブジェクト向けファイルフォーマットのサポートにのみ特化した ld の限定バージョン。 |
|
ld へのハードリンク。 |
|
指定されたオブジェクトファイル内のシンボル情報を一覧表示します。 |
|
オブジェクトファイルの変換を行います。 |
|
指定されたオブジェクトファイルの各種情報を表示します。 さまざまなオプションを用いることで特定の情報表示が可能です。 表示される情報は、コンパイル関連ツールを開発する際に有用なものです。 |
|
アーカイブの内容を索引として生成し、それをアーカイブに保存します。 索引は、アーカイブのメンバーによって定義されるすべてのシンボルの一覧により構成されます。 アーカイブのメンバーとは再配置可能なオブジェクトファイルのことです。 |
|
ELF フォーマットのバイナリファイルの情報を表示します。 |
|
指定されたオブジェクトファイルのセクションサイズと合計サイズを一覧表示します。 |
|
指定されたファイルに対して、印字可能な文字の並びを出力します。 文字は所定の長さ (デフォルトでは 4文字) 以上のものが対象となります。 オブジェクトファイルの場合デフォルトでは、初期化セクションとロードされるセクションからのみ文字列を抽出し出力します。 これ以外の種類のファイルの場合は、ファイル全体が走査されます。 |
|
オブジェクトファイルからデバッグシンボルを取り除きます。 |
|
バイナリファイルディスクリプター (Binary File Descriptor) ライブラリ。 |
|
Compat ANSI-C Type フォーマットタイプデバッギングサポートライブラリ。 |
|
libbfd の機能を利用しない libctf の互換ライブラリ。 |
|
opcodes (オペレーションコード; プロセッサー命令を「認識可能なテキスト」として表現したもの) を取り扱うライブラリ。 このライブラリは objdump のような、ビルド作業に用いるユーティリティプログラムが利用しています。 |
GMP パッケージは数値演算ライブラリを提供します。 このライブラリには任意精度演算 (arbitrary precision arithmetic) を行う有用な関数が含まれます。
32 ビット x86 CPU にて環境構築する際に、64 ビットコードを扱う CPU 環境であって
かつ CFLAGS
を指定していると、本パッケージの configure スクリプトは 64
ビット用の処理を行い失敗します。 これを回避するには、以下のように処理してください。
ABI=32
./configure ...
GMP のデフォルト設定に従うと、ホストのプロセッサー向けに最適化したライブラリを生成してしまいます。 ホストに比べて、やや性能の劣るプロセッサーに向けたライブラリを必要とする場合は、汎用ライブラリを生成するために以下を実行します。
cp -v configfsf.guess config.guess cp -v configfsf.sub config.sub
GMP をコンパイルするための準備をします。
./configure --prefix=/usr \ --enable-cxx \ --disable-static \ --docdir=/usr/share/doc/gmp-6.2.1
configure オプションの意味
--enable-cxx
C++ サポートを有効にします。
--docdir=/usr/share/doc/gmp-6.2.1
ドキュメントのインストール先を適切に設定します。
パッケージをコンパイルし HTML ドキュメントを生成します。
make make html
本節における GMP のテストスイートは極めて重要なものです。 したがってどのような場合であっても必ず実行してください。
テストを実行します。
make check 2>&1 | tee gmp-check-log
gmp のコードはビルドするプロセッサー向けに高度に最適化されます。 このためプロセッサーを特定したコードが実はシステム性能を的確に制御できないことも起こりえます。 それはテストにおいてエラーを引き起こしたり、gmp を利用する他のアプリケーションにおいて "Illegal instruction" というエラーとして発生したりすることがあります。 そういった場合は gmp の再ビルドが必要であり、その際にはオプション --build=x86_64-pc-linux-gnu をつける必要があります。
197 個のテストが完了することを確認してください。 テスト結果は以下のコマンドにより確認することができます。
awk '/# PASS:/{total+=$3} ; END{print total}' gmp-check-log
パッケージと HTML ドキュメントをインストールします。
make install make install-html
MPFR パッケージは倍精度演算 (multiple precision) の関数を提供します。
MPFR をコンパイルするための準備をします。
./configure --prefix=/usr \ --disable-static \ --enable-thread-safe \ --docdir=/usr/share/doc/mpfr-4.1.0
パッケージをコンパイルし HTML ドキュメントを生成します。
make make html
本節における MPFR のテストスイートは極めて重要なものです。 したがってどのような場合であっても必ず実行してください。
すべてのテストが正常に完了していることを確認してください。
make check
パッケージとドキュメントをインストールします。
make install make install-html
MPC パッケージは複素数演算を可能とするライブラリを提供するものです。 高い精度と適切な丸め (rounding) を実現します。
MPC をコンパイルするための準備をします。
./configure --prefix=/usr \ --disable-static \ --docdir=/usr/share/doc/mpc-1.2.1
パッケージをコンパイルし HTML ドキュメントを生成します。
make make html
コンパイル結果をテストするには以下を実行します。
make check
パッケージとドキュメントをインストールします。
make install make install-html
attr パッケージは、ファイルシステム上のオブジェクトに対しての拡張属性を管理するユーティリティを提供します。
Attr をコンパイルするための準備をします。
./configure --prefix=/usr \ --disable-static \ --sysconfdir=/etc \ --docdir=/usr/share/doc/attr-2.5.1
パッケージをコンパイルします。
make
テストは、ext2, ext3, ext4 のような拡張属性をサポートしているファイルシステム上にて実施する必要があります。 テストを実施するには以下を実行します。
make check
パッケージをインストールします。
make install
Acl パッケージは、アクセスコントロールリスト (Access Control Lists) を管理するユーティリティーを提供します。 これはファイルやディレクトリに対して、きめ細かく詳細にアクセス権限を設定するものとして利用されます。
Acl をコンパイルするための準備をします。
./configure --prefix=/usr \ --disable-static \ --docdir=/usr/share/doc/acl-2.3.1
パッケージをコンパイルします。
make
Acl のテストは、Acl のライブラリによって Coreutils をビルドした後に、アクセス制御がサポートされたファイルシステム上にて実施する必要があります。 テスト実施が必要である場合は、後に生成する Coreutils のビルドが終わってから、再び本パッケージに戻って make check を実行してください。
パッケージをインストールします。
make install
Libcap パッケージは、Linux カーネルにおいて利用される POSIX 1003.1e 機能へのユーザー空間からのインターフェースを実装します。 この機能は、強力な root 権限機能を他の権限へと分散します。
スタティックライブラリをインストールしないようにします。
sed -i '/install -m.*STA/d' libcap/Makefile
パッケージをコンパイルします。
make prefix=/usr lib=lib
make オプションの意味
lib=lib
このパラメーターは x86_64 においてライブラリを /usr/lib64
ではなく /usr/lib
にインストールするようにします。 x86
においては何も効果はありません。
ビルド結果をテストする場合は以下を実行します。
make test
パッケージをインストールします。
make prefix=/usr lib=lib install
Shadow パッケージはセキュアなパスワード管理を行うプログラムを提供します。
もっと強力なパスワードを利用したい場合は
https://www.linuxfromscratch.org/blfs/view/stable-systemd/postlfs/cracklib.html
にて示している Cracklib パッケージを参照してください。 Cracklib パッケージは Shadow
パッケージよりも前にインストールします。 その場合 Shadow パッケージの configure スクリプトでは
--with-libcrack
パラメーターをつけて実行する必要があります。
groups コマンドとその man ページをインストールしないようにします。 これは Coreutils パッケージにて、より良いバージョンが提供されているからです。 また 「Man-pages-5.13」 にてインストールされている man ページはインストールしないようにします。
sed -i 's/groups$(EXEEXT) //' src/Makefile.in find man -name Makefile.in -exec sed -i 's/groups\.1 / /' {} \; find man -name Makefile.in -exec sed -i 's/getspnam\.3 / /' {} \; find man -name Makefile.in -exec sed -i 's/passwd\.5 / /' {} \;
パスワード暗号化に関して、デフォルトの
crypt 手法ではなく、より強力な
SHA-512 手法を用いることにします。
こうしておくと 8文字以上のパスワード入力が可能となります。 またメールボックスを収めるディレクトリとして Shadow
ではデフォルトで /var/spool/mail
ディレクトリを利用していますが、これは古いものであるため /var/mail
ディレクトリに変更します。 また PATH
から /bin
と
/sbin
を削除します。 これらは /usr
からのシンボリックリンクであるからです。
何らかの理由により PATH
に対して /bin
や /sbin
を残しておく必要がある場合は、LFS ビルドが完成した後に
.bashrc
において PATH
を設定してください。
sed -e 's:#ENCRYPT_METHOD DES:ENCRYPT_METHOD SHA512:' \ -e 's:/var/spool/mail:/var/mail:' \ -e '/PATH=/{s@/sbin:@@;s@/bin:@@}' \ -i etc/login.defs
Cracklib のサポートを含めて Shadow をビルドする場合は以下を実行します。
sed -i 's:DICTPATH.*:DICTPATH\t/lib/cracklib/pw_dict:' etc/login.defs
Shadow をコンパイルするための準備をします。
touch /usr/bin/passwd ./configure --sysconfdir=/etc \ --disable-static \ --with-group-name-max-length=32
configure オプションの意味
プログラムの中には /usr/bin/passwd
のパスがそのままハードコーディングされているものがあり、このファイルが存在しなかった場合のデフォルトパスが正しくなっていません。
--with-group-name-max-length=32
ユーザー名とグループ名の最大文字数を 32 とします。
パッケージをコンパイルします。
make
このパッケージにテストスイートはありません。
パッケージをインストールします。
make exec_prefix=/usr install make -C man install-man
このパッケージには、ユーザーやグループの追加、修正、削除、そのパスワードの設定、変更、その他の管理操作を行うユーティリティが含まれます。
パスワードのシャドウイング (password
shadowing)
というものが何を意味するのか、その詳細についてはこのパッケージのソース内にある doc/HOWTO
を参照してください。 Shadow
によるサポートを利用する場合、パスワード認証を必要とするプログラム (ディスプレイマネージャー、FTP
プログラム、POP3、デーモン、など) は Shadow に準拠したものでなければなりません。
つまりそれらのプログラムが、シャドウ化された (shadowed)
パスワードを受け入れて動作しなければならないということです。
Shadow によるパスワードの利用を有効にするために、以下のコマンドを実行します。
pwconv
また Shadow によるグループパスワードを有効にするために、以下を実行します。
grpconv
Shadow の useradd
コマンドに対するデフォルトの設定には、注意すべき点があります。 まず useradd
コマンドによりユーザーを生成する場合のデフォルトの動作では、ユーザー名と同じグループを自動生成します。 ユーザーID
(UID) とグループID (GID) は 1000 以上が割り当てられます。 useradd
コマンドの利用時に特にパラメータを与えなければ、追加するユーザーのグループは新たな固有グループが生成されることになります。
この動作が不適当であれば useradd コマンドの実行時に
-g
パラメーターか -N
のいずれかを利用することが必要です。 あるいは
/etc/login.defs
内にある USERGROUPS_ENAB
の設定を書き換えてください。
詳しくは useradd(8)
を参照してください。
次にデフォルトパラメーターを変更します。 そのためにはファイル /etc/default/useradd
の生成が必要です。
特定の状況に合わせてこれを設定します。 まずは以下のようにして、このファイルを生成します。
mkdir -p /etc/default useradd -D --gid 999
/etc/default/useradd
のパラメーター説明
GROUP=999
このパラメーターは /etc/group
ファイルにおいて設定されるグループ ID の先頭番号を指定します。 999 という値は、上に示した
--gid
からきています。
必要なら任意の数値に設定することもできます。 useradd コマンドは既存の UID
値、GID 値を再利用することはありません。
このパラメーターによって指定された数値が実際に利用されていた場合、その値以降で利用可能な値が採用されます。
また useradd コマンドの実行にあたって
パラメーター -g
を利用せずに、その数値によって表される ID
を持ったグループがシステム上に存在しなかった場合は、以下のようなメッセージが出力されます。
useradd: unknown GID
999
("GID 999 が不明です") この場合でも、アカウントは正しく生成されます。
だからこそ「重要なファイルとシンボリックリンクの生成」において、グループ
ID を指定してグループ users
を生成できたわけです。
CREATE_MAIL_SPOOL=yes
このパラメーターは useradd
コマンドの実行によって、追加されるユーザー用のメールボックスに関するファイルが生成されます。
useradd
コマンドは、このファイルのグループ所有者を mail
(グループID 0660) に設定します。
メールボックスに関するファイルを生成したくない場合は、以下のコマンドを実行します。
sed -i '/MAIL/s/yes/no/' /etc/default/useradd
root ユーザーのパスワードを設定します。
passwd root
ユーザーのパスワード変更を行うべき期間を変更します。 |
|
ユーザーのフルネームや他の情報を変更します。 |
|
グループのパスワードをバッチモードにて更新します。 |
|
ユーザーのパスワードをバッチモードにて更新します。 |
|
ユーザーのデフォルトのログインシェルを変更します。 |
|
現時点でのパスワード失効に関する設定をチェックし更新します。 |
|
ログイン失敗のログを調査します。 ログインの失敗を繰り返すことでアカウントがロックされる際の、最大の失敗回数を設定します。 またその失敗回数をリセットします。 |
|
ユーザーのサブ id 範囲の一覧取得に用いられます。 |
|
グループに対してメンバーや管理者を追加、削除します。 |
|
指定した名前でグループを生成します。 |
|
指定された名前のグループを削除します。 |
|
スーパーユーザー権限を持たなくても、自分自身のグループのメンバーリストを管理可能とします。 |
|
指定されたグループの名前や GID を修正します。 |
|
グループファイル |
|
通常のグループファイルから Shadow グループファイルを生成、更新します。 |
|
|
|
全ユーザーの中での最新ログインの情報、または指定ユーザーの最新ログインの情報を表示します。 |
|
ユーザーのログインを行います。 |
|
ログオン時間とポートに対する制限を実施するためのデーモン。 |
|
ユーザー空間における gid マッピングを設定します。 |
|
ログインセッション中に現在の GID を変更します。 |
|
ユーザー空間における uid マッピングを設定します。 |
|
複数ユーザーのアカウント情報を生成または更新します。 |
|
ユーザーアカウントが利用不能であることをメッセージ表示します。 利用不能なユーザーアカウントに対するデフォルトシェルとして利用することを意図しています。 |
|
ユーザーアカウントまたはグループアカウントに対するパスワードを変更します。 |
|
パスワードファイル |
|
通常のパスワードファイルを元に shadow パスワードファイルを生成、更新します。 |
|
|
|
ユーザーの GID を指定されたグループにセットした上で、指定されたコマンドを実行します。 |
|
ユーザー ID とグループ ID を変更してシェルを実行します。 |
|
指定した名前で新たなユーザーを生成します。 あるいは新規ユーザーのデフォルトの情報を更新します。 |
|
指定されたユーザーアカウントを削除します。 |
|
指定されたユーザーのログイン名、UID (User Identification)、利用シェル、初期グループ、ホームディレクトリなどを変更します。 |
|
|
|
|
|
ユーザーに対するサブ ID 範囲を処理するライブラリ。 |
GCC パッケージは C コンパイラーや C++ コンパイラーなどの GNU コンパイラーコレクションを提供します。
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 をコンパイルするための準備をします。
../configure --prefix=/usr \ LD=ld \ --enable-languages=c,c++ \ --disable-multilib \ --disable-bootstrap \ --with-system-zlib
他のプログラミング言語は、また別の依存パッケージなどを要しますが、現時点では準備できていません。 GCC がサポートする他のプログラム言語の構築方法については BLFS ブック の説明を参照してください。
Configure パラメーターの意味
LD=ld
本パラメーターは、本章の初期段階でビルドした binutils の ld を使うことを configure スクリプトに指示します。 これを指定しなかった場合は、クロスビルド版のものが用いられることになります。
--with-system-zlib
このオプションはシステムに既にインストールされている zlib ライブラリをリンクすることを指示するものであり、内部にて作成されるライブラリを用いないようにします。
パッケージをコンパイルします。
make
本節における GCC のテストスイートは極めて重要なものです。 ただし相当な時間を要します。 初めてビルドを行う方には、必ず実施することをお勧めします。 テスト実行に要する時間は、make コマンドに -jx をつけることで、かなり削減できます。 ここに示す x には、システムのコア数を指定するものです。
GCC テストスイートの中で、デフォルトのスタックを使い果たすものがあります。 そこでテスト実施にあたり、スタックサイズを増やします。
ulimit -s 32768
一般ユーザーにてテストを行います。 ただしエラーがあっても停止しないようにします。
chown -Rv tester . su tester -c "PATH=$PATH make -k check"
テスト結果を確認するために以下を実行します。
../contrib/test_summary
テスト結果の概略のみ確認したい場合は、出力結果をパイプ出力して grep -A7 Summ
を実行してください。
テスト結果については https://www.linuxfromscratch.org/lfs/build-logs/11.2/ と https://gcc.gnu.org/ml/gcc-testresults/ にある情報と比較することができます。
g++ においては PR100400 に関連するテスト 4 つが XPASS および FAIL として出力されます。 この問題はテストファイルが適切に記述されていないために発生します。
テストに失敗することがありますが、これを回避することはできません。 GCC の開発者はこの問題を認識していますが、まだ解決していない状況です。 上記の URL に示されている結果と大きく異なっていなかったら、問題はありませんので先に進んでください。
パッケージをインストールします。
make install
GCC のビルドディレクトリの所有者は tester
であるため、ヘッダーがインストールされるディレクトリ(とその内容)に対する所有権が不適切なものになります。
そこでその所有権を root
ユーザーとグループに変更します。
chown -v -R root:root \ /usr/lib/gcc/$(gcc -dumpmachine)/12.2.0/include{,-fixed}
FHS の求めるところに応じてシンボリックリンクを作成します。 これは慣例によるものです
ln -svr /usr/bin/cpp /usr/lib
リンク時の最適化 (Link Time Optimization; LTO) によりプログラム構築できるように、シンボリックリンクを作ります。
ln -sfv ../../libexec/gcc/$(gcc -dumpmachine)/12.2.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/12.2.0/../../../../lib/crt1.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../lib/crti.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../lib/crtn.o succeeded
作業しているマシンアーキテクチャーによっては、上の結果が微妙に異なるかもしれません。 その違いは、たいていは
/usr/lib/gcc
の次のディレクトリ名にあります。
注意すべき重要な点は gcc
が crt*.o
という 3 つのファイルを
/usr/lib
配下から探し出しているということです。
コンパイラーが正しいヘッダーファイルを読み取っているかどうかを検査します。
grep -B4 '^ /usr/include' dummy.log
上のコマンドは以下の出力を返します。
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include-fixed
/usr/include
もう一度触れておきますが、プラットフォームの「三つの組 (target triplet)」の次にくるディレクトリ名は CPU アーキテクチャーにより異なる点に注意してください。
次に、新たなリンカーが正しいパスを検索して用いられているかどうかを検査します。
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 /usr/lib/libc.so.6 succeeded
GCC が正しくダイナミックリンカーを用いているかを確認します。
grep found dummy.log
上のコマンドの出力は以下のようになるはずです。 (ダイナミックリンカーの名前はプラットフォームによって違っているかもしれません。)
found ld-linux-x86-64.so.2 at /usr/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
C++ コンパイラー |
|
C コンパイラー |
|
C プリプロセッサー。 コンパイラーがこれを利用して、ソース内に記述された #include、#define や同じようなステートメントを展開します。 |
|
C++ コンパイラー |
|
C コンパイラー |
|
ar に関連するラッパーであり、コマンドラインへのプラグインを追加します。 このプログラムは「リンク時の最適化 (link time optimization)」機能を付与する場合にのみ利用されます。 デフォルトのビルドオプションでは有効にはなりません。 |
|
nm に関連するラッパーであり、コマンドラインへのプラグインを追加します。 このプログラムは「リンク時の最適化 (link time optimization)」機能を付与する場合にのみ利用されます。 デフォルトのビルドオプションでは有効にはなりません。 |
|
ranlib に関連するラッパーであり、コマンドラインへのプラグインを追加します。 このプログラムは「リンク時の最適化 (link time optimization)」機能を付与する場合にのみ利用されます。 デフォルトのビルドオプションでは有効にはなりません。 |
|
カバレッジテストツール。 プログラムを解析して、最適化が最も効果的となるのはどこかを特定します。 |
|
オフラインの gcda および gcno プロファイルダンプツール。 |
|
オフラインの gcda プロファイル処理ツール。 |
|
LTO が有効にした GCC によって生成されるオブジェクトファイルをダンプするためのツール。 |
|
アドレスサニタイザー (Address Sanitizer) のランタイムライブラリ。 |
|
GCC 不可分 (アトミック) ビルトインランタイムライブラリ。 |
|
C 言語プリプロセスライブラリ。 |
|
gcc のランタイムサポートを提供します。 |
|
GCC のプロファイリングを有効にした場合にこのライブラリがリンクされます。 |
|
C/C++ や Fortran においてマルチプラットフォームでの共有メモリ並行プログラミング (multi-platform shared-memory parallel programming) を行うための GNU による OpenMP API インプリメンテーションです。 |
|
GNU のトランザクショナル(transactional)メモリーライブラリ。 |
|
リークサニタイザー (Leak Sanitizer) のランタイムライブラリ。 |
|
GCC の LTO プラグインは、LTO を有効にした GCC から生成されたオブジェクトファイルを binnutils が処理できるようにします。 |
|
GCC の4倍精度数値演算 (Quad Precision Math) ライブラリ API |
|
GCC のスタック破壊を防止する (stack-smashing protection) 機能をサポートするルーチンを提供します。 |
|
標準 C++ ライブラリ |
|
ISO/IEC TS 18822:2015 ファイルシステムライブラリ。 |
|
C++ プログラミング言語のためのサポートルーチンを提供します。 |
|
スレッドサニタイザー (Thread Sanitizer) のランタイムライブラリ。 |
|
Undefined Behavior Sanitizer ランタイムライブラリ。 |
pkg-config パッケージは configure や make による処理において、インクルードパスやライブラリパスの情報を提供するツールです。
Pkg-config をコンパイルするための準備をします。
./configure --prefix=/usr \ --with-internal-glib \ --disable-host-tool \ --docdir=/usr/share/doc/pkg-config-0.29.2
configure オプションの意味
--with-internal-glib
これは pkg-config が内包しているバージョンの glib を利用するようにします。 LFS においては Glib をインストールせず利用できないからです。
--disable-host-tool
本オプションは、pkg-config プログラムに対しての不要なハードリンクを生成しないようにします。
パッケージをコンパイルします。
make
ビルド結果をテストする場合は以下を実行します。
make check
パッケージをインストールします。
make install
Ncurses パッケージは、端末に依存しない、文字ベースのスクリーン制御を行うライブラリを提供します。
Ncurses をコンパイルするための準備をします。
./configure --prefix=/usr \ --mandir=/usr/share/man \ --with-shared \ --without-debug \ --without-normal \ --with-cxx-shared \ --enable-pc-files \ --enable-widec \ --with-pkg-config-libdir=/usr/lib/pkgconfig
configure オプションの意味
--with-shared
これは Ncurses において共有 C ライブラリをビルドしインストールします。
--without-normal
これは Ncurses においてスタティックな C ライブラリのビルドおよびインストールを行わないようにします。
--without-debug
これは Ncurses においてデバッグライブラリのビルドおよびインストールを行わないようにします。
--with-cxx-shared
これは Ncurses において共有 C++ バインディングをビルドしインストールします。 同時にスタティックな C++ バインディングのビルドおよびインストールは行わないようにします。
--enable-pc-files
本スイッチは pkg-config 用の .pc ファイルを生成しインストールすることを指示します。
--enable-widec
本スイッチは通常のライブラリ (libncurses.so.6.3
) ではなくワイド文字対応のライブラリ
(libncursesw.so.6.3
)
をビルドすることを指示します。 ワイド文字対応のライブラリは、マルチバイトロケールと従来の
8ビットロケールの双方に対して利用可能です。 通常のライブラリでは 8ビットロケールに対してしか動作しません。
ワイド文字対応と通常のものとでは、ソース互換があるもののバイナリ互換がありません。
パッケージをコンパイルします。
make
このパッケージにテストスイートはありますが、パッケージをインストールした後でないと実行できません。
テストスイートのためのファイル群はサブディレクトリ test/
以下に残っています。 詳しいことはそのディレクトリ内にある README
ファイルを参照してください。
本パッケージをインストールすると、所定位置にある libncursesw.so.6.3
が上書きされます。
このときに、そのライブラリファイルのコードやデータを利用しているシェルプロセスが、クラッシュする場合があります。
そこで本パッケージは DESTDIR
を使ってインストールして、install
コマンドによってライブラリファイルを正しく置き換えるようにします。 configure
では取り扱われないスタティックアーカイブは不要であるため、同様に削除されます。
make DESTDIR=$PWD/dest install install -vm755 dest/usr/lib/libncursesw.so.6.3 /usr/lib rm -v dest/usr/lib/libncursesw.so.6.3 cp -av dest/* /
アプリケーションによっては、ワイド文字対応ではないライブラリをリンカーが探し出すよう求めるものが多くあります。 そのようなアプリケーションに対しては、以下のようなシンボリックリンクやリンカースクリプトを作り出して、ワイド文字対応のライブラリにリンクさせるよう仕向けます。
for lib in ncurses form panel menu ; do rm -vf /usr/lib/lib${lib}.so echo "INPUT(-l${lib}w)" > /usr/lib/lib${lib}.so ln -sfv ${lib}w.pc /usr/lib/pkgconfig/${lib}.pc done
最後に古いアプリケーションにおいて、ビルド時に -lcurses
を指定するものがあるため、これもビルド可能なものにします。
rm -vf /usr/lib/libcursesw.so echo "INPUT(-lncursesw)" > /usr/lib/libcursesw.so ln -sfv libncurses.so /usr/lib/libcurses.so
必要なら Ncurses のドキュメントをインストールします。
mkdir -pv /usr/share/doc/ncurses-6.3 cp -v -R doc/* /usr/share/doc/ncurses-6.3
ここまでの作業手順では、ワイド文字対応ではない Ncurses ライブラリは生成しませんでした。 ソースからコンパイルして構築するパッケージなら、実行時にそのようなライブラリにリンクするものはないからであり、バイナリコードのアプリケーションで非ワイド文字対応のものは Ncurses 5 にリンクされています。 バイナリコードしかないアプリケーションを取り扱う場合、あるいは LSB 対応を要する場合で、それがワイド文字対応ではないライブラリを必要とするなら、以下のコマンドによりそのようなライブラリを生成してください。
make distclean ./configure --prefix=/usr \ --with-shared \ --without-normal \ --without-debug \ --without-cxx-binding \ --with-abi-version=5 make sources libs cp -av lib/lib*.so.5* /usr/lib
termcap の記述を terminfo の記述に変換します。 |
|
画面消去が可能ならこれを行います。 |
|
terminfo の記述どうしを比較したり出力したりします。 |
|
terminfo の記述を termcap の記述に変換します。 |
|
ncurses の設定情報を提供します。 |
|
端末をデフォルト設定に初期化します。 |
|
端末上のタブストップの設定をクリアしたり設定したりします。 |
|
terminfo の定義項目に対するコンパイラーです。 これはソース形式の terminfo ファイルをバイナリ形式に変換し、ncurses ライブラリ内の処理ルーチンが利用できるようにします。 terminfo ファイルは特定端末の特性に関する情報が記述されるものです。 |
|
利用可能なすべての端末タイプを一覧表示します。 そこでは端末名と簡単な説明を示します。 |
|
端末に依存する機能設定をシェルが利用できるようにします。 また端末のリセットや初期化、あるいは長い端末名称の表示も行います。 |
|
端末の初期化に利用します。 |
|
|
|
さまざまな方法により端末画面上に文字列を表示するための関数を提供します。 これらの関数を用いた具体例として、カーネルの make menuconfig の実行によって表示されるメニューがあります。 |
|
フォームを実装するための関数を提供します。 |
|
メニューを実装するための関数を提供します。 |
|
パネルを実装するための関数を提供します。 |
Sed パッケージはストリームエディターを提供します。
Sed をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルし HTML ドキュメントを生成します。
make make html
コンパイル結果をテストするには以下を実行します。
chown -Rv tester . su tester -c "PATH=$PATH make check"
パッケージとドキュメントをインストールします。
make install install -d -m755 /usr/share/doc/sed-4.8 install -m644 doc/sed.html /usr/share/doc/sed-4.8
Psmisc パッケージは稼動中プロセスの情報表示を行うプログラムを提供します。
Psmisc をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルします。
make
このパッケージにテストスイートはありません。
パッケージをインストールします。
make install
Gettext パッケージは国際化を行うユーティリティを提供します。 各種プログラムに対して NLS (Native Language Support) を含めてコンパイルすることができます。 つまり各言語による出力メッセージが得られることになります。
Gettext をコンパイルするための準備をします。
./configure --prefix=/usr \ --disable-static \ --docdir=/usr/share/doc/gettext-0.21
パッケージをコンパイルします。
make
コンパイル結果をテストするなら (3 SBU 程度の処理時間を要しますが) 以下を実行します。
make check
パッケージをインストールします。
make install chmod -v 0755 /usr/lib/preloadable_libintl.so
Gettext 標準のインフラストラクチャーファイル (infrastructure file) をソースパッケージ内にコピーします。 |
|
環境変数をシェル書式の文字列として変換します。 |
|
メッセージカタログ内の翻訳文を参照し、メッセージをユーザーの利用言語に変換します。 |
|
主に gettext におけるシェル関数ライブラリとして機能します。 |
|
パッケージの国際化対応を始めるにあたり、標準的な Gettext 関連ファイルを、指定されたパッケージのトップディレクトリにコピーします。 |
|
翻訳カタログ内のメッセージの属性に応じて、そのメッセージを抽出します。 またメッセージの属性を操作します。 |
|
指定された |
|
二つの |
|
指定された |
|
翻訳カタログを別のキャラクターエンコーディングに変換します。 |
|
英語用の翻訳カタログを生成します。 |
|
翻訳カタログ内の翻訳文すべてに対してコマンドを適用します。 |
|
翻訳カタログ内の翻訳文すべてに対してフィルター処理を適用します。 |
|
翻訳カタログからバイナリメッセージカタログを生成します。 |
|
指定された検索パターンに合致する、あるいは指定されたソースファイルに属する翻訳カタログの全メッセージを出力します。 |
|
新規に |
|
二つの翻訳ファイルを一つにまとめます。 |
|
バイナリメッセージカタログを翻訳テキストに逆コンパイルします。 |
|
翻訳カタログ中に重複した翻訳がある場合にこれを統一します。 |
|
出力メッセージをユーザーの利用言語に変換します。 特に複数形のメッセージを取り扱います。 |
|
セルビア語のテキストに対し、キリル文字からラテン文字にコード変換します。 |
|
指定されたソースファイルから、翻訳対象となるメッセージ行を抽出して、翻訳テンプレートとして生成します。 |
|
autosprintf クラスを定義します。 これは C++ プログラムにて利用できる C 言語書式の出力ルーチンを生成するものです。 <string> 文字列と <iostream> ストリームを利用します。 |
|
さまざまな Gettext プログラムが利用している共通的ルーチンを提供するプライベートライブラリです。 これは一般的な利用を想定したものではありません。 |
|
|
|
さまざまな Gettext プログラムが利用している共通的ルーチンを提供するプライベートライブラリです。 これは一般的な利用を想定したものではありません。 |
|
テキストスタイリングライブラリ。 |
|
LD_PRELOAD が利用するライブラリ。 翻訳されていないメッセージを収集 (log) する
|
Bison パッケージは構文解析ツールを提供します。
Bison をコンパイルするための準備をします。
./configure --prefix=/usr --docdir=/usr/share/doc/bison-3.8.2
パッケージをコンパイルします。
make
コンパイル結果をテストするなら以下を実行します。(約 5.5 SBU)
make check
パッケージをインストールします。
make install
Grep パッケージはファイル内の検索を行うプログラムを提供します。
Grep をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルします。
make
コンパイル結果をテストするには以下を実行します。
make check
パッケージをインストールします。
make install
Bash は Bourne-Again SHell を提供します。
Bash をコンパイルするための準備をします。
./configure --prefix=/usr \ --docdir=/usr/share/doc/bash-5.1.16 \ --without-bash-malloc \ --with-installed-readline
configure オプションの意味
--with-installed-readline
このオプションは Bash が持つ独自の readline
ライブラリではなく、既にインストールした
readline
ライブラリを用いることを指示します。
パッケージをコンパイルします。
make
テストスィートを実行しない場合は「パッケージをインストールします。」と書かれた箇所まで読み飛ばしてください。
テストを実施するにあたっては tester
ユーザーによるソースツリーへの書き込みを可能とします。
chown -Rv tester .
本パッケージのテストスイートは、非 root
ユーザーが実行するものとされていて、利用する端末が標準入力に接続できているものとしています。
この仕様を満たすためには、Expect
を使って新たな疑似端末を起動します。 そして tester
ユーザーとしてテストを実行します。
su -s /usr/bin/expect tester << EOF set timeout -1 spawn make tests expect eof lassign [wait] _ _ _ value exit $value EOF
パッケージをインストールします。
make install
新たにコンパイルした bash プログラムを実行します。(この時点までに実行されていたものが置き換えられます。)
exec /usr/bin/bash --login
Libtool パッケージは GNU 汎用ライブラリをサポートするスクリプトを提供します。 これは複雑な共有ライブラリをラップして一貫した可搬性を実現します。
Libtool をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルします。
make
コンパイル結果をテストするには以下を実行します。
make check
マルチコアのシステム上で libtool のテストをすると、その処理時間は大幅に減ります。 実行する際には、上のコマンドに TESTSUITEFLAGS=-j<N> を加えます。 例えば -j4 を指定するとテスト時間は 6 割以上減ります。
LFS ビルド環境下では5つのテストが失敗します。 これはパッケージ間の相互依存のためです。 automake をインストールした後に再テストすれば、全テストが成功します。
パッケージをインストールします。
make install
不要なスタティックライブラリを削除します。
rm -fv /usr/lib/libltdl.a
GDBM パッケージは GNU データベースマネージャーを提供します。 これは拡張性のあるハッシングなど、従来の UNIX dbm と同様のデータベース機能を実現するライブラリです。 このライブラリにより、キーデータペアの収容、キーによるデータ検索と抽出、キーに基づいたデータ削除などを行うことができます。
GDBM をコンパイルするための準備をします。
./configure --prefix=/usr \ --disable-static \ --enable-libgdbm-compat
configure オプションの意味
--enable-libgdbm-compat
このオプションは libgdbm 互換ライブラリをビルドすることを指示します。 LFS パッケージ以外において、かつての古い DBM ルーチンを必要とするものがあるかもしれません。
パッケージをコンパイルします。
make
ビルド結果をテストする場合は以下を実行します。
make check
パッケージをインストールします。
make install
Gperf は、キーセットに基づいて完全なハッシュ関数の生成を実現します。
Gperf をコンパイルするための準備をします。
./configure --prefix=/usr --docdir=/usr/share/doc/gperf-3.1
パッケージをコンパイルします。
make
同時実行によるテスト (-j オプションを 1 より大きくした場合) ではテストに失敗します。 ビルド結果をテストする場合は以下を実行します。
make -j1 check
パッケージをインストールします。
make install
Expat パッケージは XML を解析するためのストリーム指向 (stream oriented) な C ライブラリを提供します。
Expat をコンパイルするための準備をします。
./configure --prefix=/usr \ --disable-static \ --docdir=/usr/share/doc/expat-2.4.8
パッケージをコンパイルします。
make
ビルド結果をテストする場合は以下を実行します。
make check
パッケージをインストールします。
make install
必要ならドキュメントをインストールします。
install -v -m644 doc/*.{html,css} /usr/share/doc/expat-2.4.8
Inetutils パッケージはネットワーク制御を行う基本的なプログラムを提供します。
Inetutils をコンパイルするための準備をします。
./configure --prefix=/usr \ --bindir=/usr/bin \ --localstatedir=/var \ --disable-logger \ --disable-whois \ --disable-rcp \ --disable-rexec \ --disable-rlogin \ --disable-rsh \ --disable-servers
configure オプションの意味
--disable-logger
このオプションは logger プログラムをインストールしないようにします。 このプログラムはシステムログデーモンに対してメッセージ出力を行うスクリプトにて利用されます。 ここでこれをインストールしないのは、後に Util-linux パッケージにおいて、より最新のバージョンをインストールするためです。
--disable-whois
このオプションは whois のクライアントプログラムをインストールしないようにします。 このプログラムはもはや古いものです。 より良い whois プログラムのインストール手順については BLFS ブックにて説明しています。
--disable-r*
これらのパラメーターは、セキュリティの問題により用いるべきではない古いプログラムを作らないようにします。 古いプログラムによる機能は BLFS ブックにて示す openssh でも提供されています。
--disable-servers
このオプションは Inetutils パッケージに含まれるさまざまなネットワークサーバーをインストールしないようにします。 これらのサーバーは基本的な LFS システムには不要なものと考えられます。 サーバーの中には本質的にセキュアでないものがあり、信頼のあるネットワーク内でのみしか安全に扱うことができないものもあります。 サーバーの多くは、これに代わる他の適切なものが存在します。
パッケージをコンパイルします。
make
コンパイル結果をテストするには以下を実行します。
make check
パッケージをインストールします。
make install
各種プログラムを適切な場所に移動します。
mv -v /usr/{,s}bin/ifconfig
システムの DNS ドメイン名を表示します。 |
|
ファイル転送プロトコル (file transfer protocol) に基づくプログラム。 |
|
ホスト名の表示または設定を行います。 |
|
ネットワークインターフェースを管理します。 |
|
エコーリクエスト (echo-request) パケットを送信し、返信にどれだけ要したかを表示します。 |
|
IPv6 ネットワーク向けの ping |
|
他ユーザーとのチャットに利用します。 |
|
TELNET プロトコルインターフェース。 |
|
軽量なファイル転送プログラム。(trivial file transfer program) |
|
処理起動したホストからネットワーク上の他のホストまで、送出したパケットの経由ルートを追跡します。 その合間に検出されたすべての hops (= ゲートウェイ) も表示します。 |
Less パッケージはテキストファイルビューアーを提供します。
Less をコンパイルするための準備をします。
./configure --prefix=/usr --sysconfdir=/etc
configure オプションの意味
--sysconfdir=/etc
本パッケージによって作成されるプログラムが /etc
ディレクトリにある設定ファイルを参照するように指示します。
パッケージをコンパイルします。
make
このパッケージにテストスイートはありません。
パッケージをインストールします。
make install
Perl パッケージは Perl 言語 (Practical Extraction and Report Language) を提供します。
ここでビルドするバージョンの Perl は Compress::Raw::Zlib モジュールと Compress::Raw::Bzip2 モジュールをビルドします。 しかしデフォルトでは内部にコピーされたライブラリソースを用いてビルドを行います。 以下のコマンドは、既にインストールされているライブラリを用いるようにします。
export BUILD_ZLIB=False export BUILD_BZIP2=0
Perl のビルド設定を完全に制御したい場合は、以下のコマンドから「-des」オプションを取り除くことで手動設定を進めることもできます。 Perl が自動判別するデフォルト設定に従うので良ければ、以下のコマンドにより Perl をコンパイルするための準備をします。
sh Configure -des \ -Dprefix=/usr \ -Dvendorprefix=/usr \ -Dprivlib=/usr/lib/perl5/5.36/core_perl \ -Darchlib=/usr/lib/perl5/5.36/core_perl \ -Dsitelib=/usr/lib/perl5/5.36/site_perl \ -Dsitearch=/usr/lib/perl5/5.36/site_perl \ -Dvendorlib=/usr/lib/perl5/5.36/vendor_perl \ -Dvendorarch=/usr/lib/perl5/5.36/vendor_perl \ -Dman1dir=/usr/share/man/man1 \ -Dman3dir=/usr/share/man/man3 \ -Dpager="/usr/bin/less -isR" \ -Duseshrplib \ -Dusethreads
configure オプションの意味
-Dvendorprefix=/usr
このオプションは各種の perl モジュールをどこにインストールするかを指定します。
-Dpager="/usr/bin/less
-isR"
このオプションは more プログラムでなく less プログラムが利用されるようにします。
-Dman1dir=/usr/share/man/man1
-Dman3dir=/usr/share/man/man3
まだ Groff をインストールしていないので Configure スクリプトが Perl の man ページを必要としないと判断してしまいます。 このオプションを指定することによりその判断を正します。
-Duseshrplib
Perl モジュールの中で必要とされる共有ライブラリ libperl をビルドします。
-Dusethreads
スレッドサポートをビルドします。
-Dprivlib,-Darchlib,-Dsitelib,...
この設定は、Perl がインストール済のモジュールを探す場所を指定します。 LFS 編集者はディレクトリ構造として Perl の Major.Minor バージョン (5.36) の形に基づいて、インストールモジュールを配置することにしています。 このようにしておくと、新たなパッチレベル (5.36.0) によるアップグレードの際に、モジュールを再インストールする必要がなくなるためです。
パッケージをコンパイルします。
make
コンパイル結果をテストするには以下を実行します。(約 11 SBU)
make test
パッケージはインストールしクリーンアップします。
make install unset BUILD_ZLIB BUILD_BZIP2
Module::CoreList に対するコマンドラインフロントエンド。 |
|
コマンドラインから CPAN (Comprehensive Perl Archive Network) との通信を行います。 |
|
Unicode キャラクターマッピングまたは Tcl エンコーディングファイルから Perl の Encode 拡張モジュールを構築します。 |
|
複数ファイルのエンコーディングを調査します。 |
|
C 言語のヘッダーファイル |
|
C 言語のヘッダーファイル |
|
インストールされている Perl モジュールを調査するシェルスクリプト。 インストールされたモジュールから tarball を作ることもできます。 |
|
特定の入出力フォーマット間でデータを変換します。 |
|
Perl モジュール |
|
C 言語、sed、awk、sh の持つ機能を寄せ集めて出来上がった言語。 |
|
perl へのハードリンク。 |
|
Perl およびそのモジュールに関するバグ報告を生成して、電子メールを送信します。 |
|
pod フォーマットのドキュメントを表示します。 pod フォーマットは Perl のインストールツリーあるいは Perl スクリプト内に埋め込まれています。 |
|
Perl Installation Verification Procedure のこと。 Perl とライブラリが正しくインストールできているかを調べるものです。 |
|
感謝のメッセージ (Thank you messages) を電子メールで Perl 開発者に送信します。 |
|
キャラクターエンコーディングを変換する iconv の Perl バージョン。 |
|
Perl4 の |
|
pod フォーマットから HTML フォーマットに変換します。 |
|
pod データを *roff の入力ファイル形式に変換します。 |
|
pod データをアスキーテキスト形式に変換します。 |
|
ファイル内に埋め込まれた pod ドキュメントから使用方法の記述部分を表示します。 |
|
pod 形式の文書ファイルに対して文法をチェックします。 |
|
pod ドキュメントに対して指定したセクションを表示します。 |
|
Test::Harness モジュールのテストを行うコマンドラインツール。 |
|
Perl で書かれた tar 相当のプログラム。 |
|
アーカイブの抽出前後を比較する Perl プログラム。 |
|
tar アーカイブ内のファイルに対してパターンマッチングを適用するための Perl プログラム。 |
|
SHA チェックサム値を表示またはチェックします。 |
|
Perl スクリプトの警告エラーの診断結果を詳細 (verbose) に出力するために利用します。 |
|
Perl の XS コードを C 言語コードに変換します。 |
|
Zip ファイルの内部構造に関する情報を出力します。 |
XML::Parser モジュールは James Clark 氏による XML パーサー Expat への Perl インターフェースです。
XML::Parser をコンパイルするための準備をします。
perl Makefile.PL
パッケージをコンパイルします。
make
ビルド結果をテストする場合は以下を実行します。
make test
パッケージをインストールします。
make install
Intltool パッケージは、プログラムソースファイルから翻訳対象の文字列を抽出するために利用する国際化ツールです。
perl-5.22 以降にて発生する警告メッセージを修正します。
sed -i 's:\\\${:\\\$\\{:' intltool-update.in
上の正規表現は、バックスラッシュが多すぎて変に思うかもしれません。 ここで行っているのは '\${' という記述の並びに対して、右ブレースの前にバックスラッシュを追加して '\$\{' を作り出しています。
Intltool をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルします。
make
ビルド結果をテストする場合は以下を実行します。
make check
パッケージをインストールします。
make install install -v -Dm644 doc/I18N-HOWTO /usr/share/doc/intltool-0.51.0/I18N-HOWTO
Autoconf パッケージは、ソースコードを自動的に設定するシェルスクリプトの生成を行うプログラムを提供します。
Autoconf をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルします。
make
ビルド結果をテストするには、以下を実行します。
make check
マルチコアのシステム上で autoconf のテストをすると、その処理時間は大幅に減ります。 実行する際には、上のコマンドに TESTSUITEFLAGS=-j<N> を加えます。 例えば -j4 を指定するとテスト時間は 6 割以上減ります。
パッケージをインストールします。
make install
ソースコードを提供するソフトウェアパッケージを自動的に設定する (configure する) シェルスクリプトを生成します。 これにより数多くの Unix 互換システムへの適用を可能とします。 生成される設定 (configure) スクリプトは独立して動作します。 つまりこれを実行するにあたっては autoconf プログラムを必要としません。 |
|
C言語の #define 文を configure が利用するためのテンプレートファイルを生成するツール。 |
|
M4 マクロプロセッサーに対するラッパー。 |
|
autoconf と automake のテンプレートファイルが変更された時に、自動的に autoconf、 autoheader、aclocal、automake、gettextize、libtoolize を無駄なく適正な順で実行します。 |
|
ソフトウェアパッケージに対する |
|
|
|
ソフトウェアパッケージにおける |
Automake パッケージは Autoconf が利用する Makefile などを生成するプログラムを提供します。
Automake をコンパイルするための準備をします。
./configure --prefix=/usr --docdir=/usr/share/doc/automake-1.16.5
パッケージをコンパイルします。
make
make オプションの -j4 を用いるとテストを速く進めることができます。 たとえ 1 つのプロセッサーであっても有用であり、個々のテストにおける内部遅延に関係するためです。 ビルド結果をテストするには以下を実行します。
make -j4 check
テスト t/subobj.sh は失敗します。
パッケージをインストールします。
make install
OpenSSL パッケージは暗号化に関する管理ツールやライブラリを提供します。 これを利用することにより、他のパッケージにおいて暗号化機能が実現されます。 例えば OpenSSH、Email アプリケーション、(HTTPS サイトアクセスを行う)ウェブブラウザーなどです。
OpenSSL をコンパイルするための準備をします。
./config --prefix=/usr \ --openssldir=/etc/ssl \ --libdir=lib \ shared \ zlib-dynamic
パッケージをコンパイルします。
make
ビルド結果をテストする場合は以下を実行します。
make test
カーネル設定によっては (CONFIG_CRYPTO_USER_API* の設定に一貫性がないと)、30-test_afalg.t というテストが 1 つだけ失敗することがわかっています。 失敗しても、無視してかまいません。
パッケージをインストールします。
sed -i '/INSTALL_LIBS/s/libcrypto.a libssl.a//' Makefile make MANSUFFIX=ssl install
ドキュメントディレクトリにバージョンを含めます。 他のパッケージとの整合をとるためです。
mv -v /usr/share/doc/openssl /usr/share/doc/openssl-3.0.5
必要であれば、さらにドキュメントをインストールします。
cp -vfr doc/* /usr/share/doc/openssl-3.0.5
ぜい弱性への対処を行った新バージョンが公開されたら、OpenSSL をアップデートすることになります。 OpenSSL
3.0.0 以降では、バージョンのつけ方が MAJOR.MINOR.PATCH という形式になりました。
API/API の互換性は、同一の MAJOR バージョン番号では保証されます。 本パッケージは
libcrypto.so
または libssl.so
へのリンクを行っていますが、LFS
では共有ライブラリをインストールするだけなので、MAJOR
バージョン番号が同一のアップグレードである限り
は、パッケージを再コンパイルする必要はありません。
そうであっても、それらのライブラリにリンクしているプログラムが稼働中であるなら、一度停止してから再起動することが必要です。 詳しくは関連する話が 「アップグレードに関する問題」 にあるので参照してください。
ディレクトリ内のすべてのファイルをスキャンする Perl スクリプト。 それらのファイルに対するハッシュ値へのシンボリックリンクを生成します。 c_rehash の利用は非推奨と考えられており、この代わりに openssl rehash コマンドを使ってください。 |
|
OpenSSL の暗号化ライブラリが提供するさまざまな関数を、シェルから利用するためのコマンドラインツール。 man 1 openssl に示される数多くの関数を利用することができます。 |
|
各種のインターネット標準にて採用されている暗号化アルゴリズムを幅広く実装しています。 このライブラリが提供する機能は、SSL、TLS、S/MIME を実装する OpenSSL において利用されており、また OpenSSH、OpenPGP、あるいはこの他の暗号化標準の実装にも利用されています。 |
|
トランスポート層セキュリティ(Transport Layer Security; TLFS v1)プロトコルを実装しています。 これは豊富な API 関数とそのドキュメントを提供します。 ドキュメントは man 3 ssl の実行により参照できます。 |
Kmod パッケージは、カーネルモジュールをロードするためのライブラリやユーティリティーを提供します。
Kmod をコンパイルするための準備をします。
./configure --prefix=/usr \ --sysconfdir=/etc \ --with-openssl \ --with-xz \ --with-zstd \ --with-zlib
configure オプションの意味
--with-openssl
このオプションは Kmod において、カーネルモジュールに対する PKCS7 署名を取り扱えるようにします。
--with-xz
, --with-zlib
, --with-zstd
これらのオプションは、Kmod が圧縮されたカーネルモジュールを取り扱えるようにするものです。
パッケージをコンパイルします。
make
本パッケージのテストスイートでは、 生のカーネルヘッダー(以前にインストールした「健全化(sanitized)」されたヘッダーではないもの)が必要です。 これは LFS の範囲を超えているものです。
パッケージインストールし、Module-Init-Tools パッケージとの互換性を保つためにシンボリックリンクを生成します。 Module-Init-Tools パッケージは、これまで Linux カーネルモジュールを取り扱っていたものです。
make install for target in depmod insmod modinfo modprobe rmmod; do ln -sfv ../bin/kmod /usr/sbin/$target done ln -sfv kmod /usr/bin/lsmod
存在しているモジュール内に含まれるシンボル名に基づいて、モジュールの依存関係を記述したファイル (dependency file) を生成します。 これは modprobe が必要なモジュールを自動的にロードするために利用します。 |
|
稼動中のカーネルに対してロード可能なモジュールをインストールします。 |
|
カーネルモジュールのロード、アンロードを行います。 |
|
その時点でロードされているモジュールを一覧表示します。 |
|
カーネルモジュールに関連付いたオブジェクトファイルを調べて、出来る限りの情報を表示します。 |
|
depmod によってモジュールの依存関係を記述したファイル (dependency file) が生成されます。 これを使って関連するモジュールを自動的にロードします。 |
|
稼動中のカーネルからモジュールをアンロードします。 |
|
このライブラリは、カーネルモジュールのロード、アンロードを行う他のプログラムが利用します。 |
Libelf は、ELF(Executable and Linkable Format)形式のファイルを扱うライブラリを提供します。
Libelf は elfutils-0.187 パッケージに含まれます。 ソース tarball として elfutils-0.187.tar.bz2 を利用します。
Libelf をコンパイルするための準備をします。
./configure --prefix=/usr \ --disable-debuginfod \ --enable-libdebuginfod=dummy
パッケージをコンパイルします。
make
ビルド結果をテストする場合は以下を実行します。
make check
Libelf のみをインストールします。
make -C libelf install install -vm644 config/libelf.pc /usr/lib/pkgconfig rm /usr/lib/libelf.a
Libffi ライブラリは、さまざまな呼出規約(calling conventions)に対しての、移植性に優れた高レベルのプログラミングインターフェースを提供します。 このライブラリを用いることで、プログラム実行時に呼出インターフェース記述(call interface description)による関数を指定して呼び出すことができるようになります。
GMP と同じように libffi では、利用中のプロセッサーに応じた最適化を行なってビルドされます。
異なるシステムに向けてのビルドを行う場合は、以下のコマンドにおいて --with-gcc-arch=
を使って、そのシステム上の CPU の実装を完全に表すアーキテクチャー名に変更してください。
そうしなかった場合には、libffi をリンクするアプリケーションにおいて Illegal Operation
エラーを発生させることになります。
ibffi をコンパイルするための準備をします。
./configure --prefix=/usr \ --disable-static \ --with-gcc-arch=native \ --disable-exec-static-tramp
configure オプションの意味
--with-gcc-arch=native
現状のシステムに応じて GCC が最適化されるようにします。 仮にこれを指定しなかった場合、システムを誤認して誤ったコードを生成してしまう場合があります。 生成されたコードが、より劣ったシステム向けのネイティブコードをコピーしていたとすると、より劣ったシステムに対するパラメーターを指定することとなります。 システムに応じた詳細は the x86 options in the GCC manual を参照してください。
--disable-exec-static-tramp
スタティックなトランポリン (trampoline) サポートを無効にします。 これは libffi における新しいセキュリティ機能ですが、BLFS パッケージの中 (特に GJS) では、この機能に対応していないものがあります。
パッケージをコンパイルします。
make
ビルド結果をテストする場合は、以下を実行します。
make check
パッケージをインストールします。
make install
Python 3 パッケージは Python 開発環境を提供します。 オブジェクト指向プログラミング、スクリプティング、大規模プログラムのプロトタイピング、アプリケーション開発などに有用なものです。
Python をコンパイルするための準備をします。
./configure --prefix=/usr \ --enable-shared \ --with-system-expat \ --with-system-ffi \ --enable-optimizations
configure オプションの意味
--with-system-expat
本スイッチは、システムにインストールされている Expat をリンクすることを指示します。
--with-system-ffi
本スイッチは、システムにインストールされている libffi をリンクすることを指示します。
--enable-optimizations
本スイッチは安定的ではあるものの高くつく最適化を有効にします。
パッケージをコンパイルします。
make
この時点においてテスト実行することはお勧めしません。 部分的にしか仕上がっていない LFS 環境では安定せずハングすることがあります。 テストを必要とする場合は、本章を一番最後まで進めてから再度実行するか、あるいは BLFS において Python 3 をインストール際に行います。 そうではなくここでテスト実行をするなら make test を実行します。
パッケージをインストールします。
make install
いくつかの場面において Python 3
プログラムやモジュールをインストールする際には、全ユーザー向けのインストールを行うために root
ユーザーになって pip3 コマンドを用いています。 このことは
Python 開発者が推奨している、仮想環境内にて一般ユーザーにより(そのユーザーが pip3
を実行することで)パッケージビルドを行う方法とは相容れないものです。 これを行っているため、root
ユーザーとして pip3
を用いると、警告メッセージが複数出力されます。
開発者がなぜその方法を推奨しているかというと、システムパッケージマネージャー(たとえば dpkg)などと衝突が発生するからです。 LFS
ではシステムワイドなパッケージマネージャーを利用していないため、このことは問題となりません。 また
pip3
そのものが、自分の最新版が存在していないかどうかを実行時に確認します。 LFS の chroot
環境においては、ドメイン名解決がまだ設定されていないので、最新版の確認は失敗して警告が出力されます。 LFS
システムを再起動してネットワーク設定を行えば、最新版の存在時には、あらかじめビルドされていた wheel を PyPI
から更新するような警告メッセージが示されます。 もっとも LFS では pip3 を Python 3
の一部として考えるので、個別に更新しないでください。 したがってあらかじめビルドされた wheel
を更新することは、ソースコードから Linux システムをビルドするという目的から逸脱してしまいます。
このことから、最新版の pip3 を求める警告も無視してください。
警告メッセージを省略したい場合は、以下のコマンドを実行します。
cat > /etc/pip.conf << EOF [global] root-user-action = ignore disable-pip-version-check = true EOF
LFS や BLFS においては通常、Python モジュールのビルドとインストールには pip3 コマンドを用いています。
この両ブックにおいて実行する pip3
install コマンドは、Python 仮想環境内でない場合には
root
ユーザーで実行するようにしてください。
root
ユーザー以外によって
pip3 install
を実行しても問題なく動作するように見えるかもしれませんが、インストールしたモジュールが別のユーザーからはアクセスできない事態を作り出してしまいます。
pip3 install
はデフォルトでは、すでにインストールされているモジュールを再インストールすることは行いません。
pip3 install
コマンドを使ってモジュールのアップグレードを行う(たとえば meson-0.61.3 から meson-0.62.0
にするような場合)には、コマンドラインに --upgrade
オプションを含めてください。
またモジュールのダウングレードや再インストールが必要となる理由が確実にあるのであれば、コマンドラインに
--force-reinstall
--no-deps
を含めて実行してください。
必要なら、整形済みドキュメントをインストールします。
install -v -dm755 /usr/share/doc/python-3.10.6/html tar --strip-components=1 \ --no-same-owner \ --no-same-permissions \ -C /usr/share/doc/python-3.10.6/html \ -xvf ../python-3.10.6-docs-html.tar.bz2
ドキュメント install コマンドの意味
--no-same-owner
と --no-same-permissions
インストールするファイルの所有者とパーミッションを適切に設定します。 このオプションがないと tar によって展開されるファイルは、アップストリームが作り出した値になってしまうためです。
Python 2.x のソースコードを読み込み、種々の変更を行って Python 3.x 用の適正なソースコードに変換するための Python プログラムです |
|
Python に特化した GUI エディターを起動するラッパースクリプト。 このスクリプトを実行するには、Python より前に Tk をインストールして、Python モジュールである Tkinter をビルドしておく必要があります。 |
|
Python のパッケージインストーラー。 この pip を使って Python Package Index などのインデックスサイトから各種パッケージをインストールできます。 |
|
Python ドキュメントツール。 |
|
インタープリターであり、対話的なオブジェクト指向プログラミング言語。 |
Wheel は Python wheel パッケージング標準に基づいた標準実装の Python ライブラリです。
以下のコマンドを実行して wheel をインストールします。
pip3 install --no-index $PWD
pip3 オプションの意味
パッケージをインストールします。
--no-index
pip がオンラインパッケージリポジトリ(PyPI) からファイルを取得しないようにします。 パッケージ類が適切な順番でインストールされていれば、最初にファイルを取得しておく必要はないはずです。 ただしこのオプションをつけておくことで、ユーザーが操作を誤っても安全であるようにします。
$PWD
インストールするファイルを現在のワーキングディレクトリ内から探し出します。
このパッケージは、処理速度を重視した軽量なビルドシステムを提供します。
ninja は同時に最大数のプロセスにより処理実行します。 そのプロセス数はデフォルトでは、システムのコア数に 2 を加えたものとなります。 このことが CPU をオーバーヒートさせたり、out of memory を引き起こす場合があります。 コマンドラインから実行する場合には -jN パラメーターを使って、並行プロセスの数を制御することもできます。 ただ ninja の実行を組み込んでいるパッケージの場合は -j パラメーターを与えることができません。
以降に示す 任意 の手順を用いると、並行プロセス数を環境変数 NINJAJOBS から制御できるようになります。 たとえば 以下のように設定します。
export NINJAJOBS=4
こうすると ninja の並行プロセスを 4 つに制限できます。
必要な場合は、環境変数 NINJAJOBS を利用するために以下を実行します。
sed -i '/int Guess/a \ int j = 0;\ char* jobs = getenv( "NINJAJOBS" );\ if ( jobs != NULL ) j = atoi( jobs );\ if ( j > 0 ) return j;\ ' src/ninja.cc
以下を実行して ninja をビルドします。
python3 configure.py --bootstrap
build オプションの意味
--bootstrap
本パラメーターは、この時点でのシステムに対して ninja 自身を再ビルドすることを指示します。
ビルド結果をテストする場合は、以下を実行します。
./ninja ninja_test ./ninja_test --gtest_filter=-SubprocessTest.SetWithLots
パッケージをインストールします。
install -vm755 ninja /usr/bin/ install -vDm644 misc/bash-completion /usr/share/bash-completion/completions/ninja install -vDm644 misc/zsh-completion /usr/share/zsh/site-functions/_ninja
Meson はオープンソースによるビルドシステムです。 非常に高速であり、できるかぎりユーザーフレンドリーであることを意識しています。
Meson をビルドするには、以下のコマンドを実行します。
pip3 wheel -w dist --no-build-isolation --no-deps $PWD
このテストスイートには、LFS の範囲外としているパッケージがいくつか必要です。
パッケージをインストールします。
pip3 install --no-index --find-links dist meson install -vDm644 data/shell-completions/bash/meson /usr/share/bash-completion/completions/meson install -vDm644 data/shell-completions/zsh/_meson /usr/share/zsh/site-functions/_meson
install パラメーターの意味
-w
dist
生成された wheel を dist
ディレクトリに配置します。
--find-links dist
dist
ディレクトリから wheel
をインストールします。
Coreutils パッケージはシステムの基本的な特性を表示したり設定したりするためのユーティリティを提供します。
POSIX によると Coreutils により生成されるプログラムは、マルチバイトロケールであっても文字データを正しく取り扱うことを求めています。 以下のパッチは標準に準拠することと、国際化処理に関連するバグを解消することを行います。
patch -Np1 -i ../coreutils-9.1-i18n-1.patch
このパッチには以前は多くのバグがありました。 新たなバグを発見したら Coreutils の開発者に報告する前に、このパッチの適用前でもバグが再現するかどうかを確認してください。
Coreutils をコンパイルするための準備をします。
autoreconf -fiv FORCE_UNSAFE_CONFIGURE=1 ./configure \ --prefix=/usr \ --enable-no-install-program=kill,uptime
configure オプションの意味
国際化対応を行うパッチによって、当パッケージのビルドシステムが修正されます。 したがって設定ファイル類を再生成する必要があります。
FORCE_UNSAFE_CONFIGURE=1
この環境変数は root
ユーザーによりパッケージをビルドできるようにします。
--enable-no-install-program=kill,uptime
指定のプログラムは、後に他のパッケージからインストールするため Coreutils からはインストールしないことを指示します。
パッケージをコンパイルします。
make
テストスイートを実行しない場合は「パッケージをインストールします。」と書かれたところまで読み飛ばしてください。
ここからテストスイートを実施していきます。 まずは root
ユーザーに対するテストを実行します。
make NON_ROOT_USERNAME=tester check-root
ここからは tester
ユーザー向けのテストを実行します。 ただしテストの中には、複数のグループに属するユーザーを必要とするものがあります。
そのようなテストが確実に実施されるように、一時的なグループを作って tester
ユーザーがそれに属するようにします。
echo "dummy:x:102:tester" >> /etc/group
特定のファイルのパーミッションを変更して root
ユーザー以外でもコンパイルとテストができるようにします。
chown -Rv tester .
テストを実行します。
su tester -c "PATH=$PATH make RUN_EXPENSIVE_TESTS=yes check"
sort-NaN-infloop というテストは GCC-12 を用いると失敗します。
一時的に作成したグループを削除します。
sed -i '/dummy/d' /etc/group
パッケージをインストールします。
make install
FHS が規定しているディレクトリにプログラムを移します。
mv -v /usr/bin/chroot /usr/sbin mv -v /usr/share/man/man1/chroot.1 /usr/share/man/man8/chroot.8 sed -i 's/"1"/"8"/' /usr/share/man/man8/chroot.8
実際のコマンドは /usr/bin/[ であり、これは test コマンドへのシンボリックリンクです。 |
|
base32 規格 (RFC 4648) に従ってデータのエンコード、デコードを行います。 |
|
base64 規格 (RFC 3548) に従ってデータのエンコード、デコードを行います。 |
|
Prints or checks BLAKE2 (512-bit) checksums |
|
ファイル名からパス部分と指定されたサフィックスを取り除きます。 |
|
各種アルゴリズムを利用したデータのエンコード、出コードを行います。 |
|
複数ファイルを連結して標準出力へ出力します。 |
|
ファイルやディレクトリに対してセキュリティコンテキスト (security context) を変更します。 |
|
ファイルやディレクトリのグループ所有権を変更します。 |
|
指定されたファイルのパーミッションを指定されたモードに変更します。 モードは、変更内容を表す文字表現か8進数表現を用いることができます。 |
|
ファイルやディレクトリの所有者またはグループを変更します。 |
|
指定したディレクトリを |
|
指定された複数ファイルについて、CRC (Cyclic Redundancy Check; 巡回冗長検査) チェックサム値とバイト数を表示します。 |
|
ソート済の二つのファイルを比較して、一致しない固有の行と一致する行を三つのカラムに分けて出力します。 |
|
ファイルをコピーします。 |
|
指定されたファイルを複数の新しいファイルに分割します。 分割は指定されたパターンか行数により行います。 そして分割後のファイルにはバイト数を出力します。 |
|
指定されたフィールド位置や文字位置によってテキスト行を部分的に取り出します。 |
|
指定された書式により現在時刻を表示します。 またはシステム日付を設定します。 |
|
指定されたブロックサイズとブロック数によりファイルをコピーします。 変換処理を行うことができます。 |
|
マウントされているすべてのファイルシステムに対して、ディスクの空き容量 (使用量) を表示します。 あるいは指定されたファイルを含んだファイルシステムについてのみの情報を表示します。 |
|
指定されたディレクトリの内容を一覧表示します。(ls コマンドに同じ。) |
|
環境変数 |
|
ファイル名からディレクトリ名以外のサフィックスを取り除きます。 |
|
カレントディレクトリ、指定ディレクトリ (サブディレクトリを含む)、指定された個々のファイルについて、それらが利用しているディスク使用量を表示します。 |
|
指定された文字列を表示します。 |
|
環境設定を変更してコマンドを実行します。 |
|
タブ文字を空白文字に変換します。 |
|
表現式を評価します。 |
|
指定された整数値すべてに対する素因数 (prime factor) を表示します。 |
|
何も行わず処理に失敗します。 これは常に失敗を意味するステータスコードを返して終了します。 |
|
指定されたファイル内にて段落を整形します。 |
|
指定されたファイル内の行を折り返します。 |
|
ユーザーの所属グループを表示します。 |
|
指定されたファイルの先頭10行 (あるいは指定された行数) を表示します。 |
|
ホスト識別番号 (16進数) を表示します。 |
|
現在のユーザーあるいは指定されたユーザーについて、有効なユーザーID、グループID、所属グループを表示します。 |
|
ファイルコピーを行います。その際にパーミッションモードを設定し、可能なら所有者やグループも設定します。 |
|
2つのファイル内にて共通項を持つ行を結合します。 |
|
指定された名称によりファイルへのハードリンクを生成します。 |
|
ファイルに対するハードリンク、あるいはソフトリンク (シンボリックリンク) を生成します。 |
|
現在のユーザーのログイン名を表示します。 |
|
指定されたディレクトリ内容を一覧表示します。 |
|
MD5 (Message Digest 5) チェックサム値を表示、あるいはチェックします。 |
|
指定された名前のディレクトリを生成します。 |
|
指定された名前の FIFO (First-In, First-Out) を生成します。 これは UNIX の用語で "名前付きパイプ (named pipe)" とも呼ばれます。 |
|
指定された名前のデバイスノードを生成します。 デバイスノードはキャラクター型特殊ファイル (character special file)、ブロック特殊ファイル (block special file)、FIFO です。 |
|
安全に一時ファイルを生成します。 これはスクリプト内にて利用されます。 |
|
ファイルあるいはディレクトリを移動、名称変更します。 |
|
スケジューリング優先度を変更してプログラムを実行します。 |
|
指定されたファイル内の行を数えます。 |
|
ハングアップに関係なくコマンドを実行します。 その出力はログファイルにリダイレクトされます。 |
|
プロセスが利用可能なプロセスユニット (processing unit) の数を表示します。 |
|
記述された文字列と数値を互いに変換します。 |
|
ファイル内容を 8進数または他の書式でダンプします。 |
|
指定された複数ファイルを結合します。 その際には各行を順に並べて結合し、その間をタブ文字で区切ります。 |
|
ファイル名が有効で移植可能であるかをチェックします。 |
|
軽量な finger クライアント。 指定されたユーザーに関する情報を表示します。 |
|
ファイルを印刷するために、ページ番号を振りカラム整形を行います。 |
|
環境変数の内容を表示します。 |
|
指定された引数を指定された書式で表示します。 C 言語の printf 関数に似ています。 |
|
指定されたファイル内のキーワードに対して整列済インデックス (permuted index) を生成します。 |
|
現在の作業ディレクトリ名を表示します。 |
|
指定されたシンボリックリンクの対象を表示します。 |
|
解析されたパスを表示します。 |
|
ファイルまたはディレクトリを削除します。 |
|
ディレクトリが空である時にそのディレクトリを削除します。 |
|
指定されたセキュリティコンテキストでコマンドを実行します。 |
|
指定された範囲と増分に従って数値の並びを表示します。 |
|
160 ビットの SHA1 (Secure Hash Algorithm 1) チェックサム値を表示またはチェックします。 |
|
224 ビットの SHA1 チェックサム値を表示またはチェックします。 |
|
256 ビットの SHA1 チェックサム値を表示またはチェックします。 |
|
384 ビットの SHA1 チェックサム値を表示またはチェックします。 |
|
512 ビットの SHA1 チェックサム値を表示またはチェックします。 |
|
指定されたファイルに対して、複雑なパターンデータを繰り返し上書きすることで、データ復旧を困難なものにします。 |
|
テキスト行を入れ替えます。 |
|
指定時間だけ停止します。 |
|
指定されたファイル内の行をソートします。 |
|
指定されたファイルを、バイト数または行数を指定して分割します。 |
|
ファイルやファイルシステムのステータスを表示します。 |
|
標準ストリームのバッファリング操作を変更してコマンド実行します。 |
|
端末回線の設定や表示を行います。 |
|
指定されたファイルのチェックサムやブロック数を表示します。 |
|
ファイルシステムのバッファを消去します。 変更のあったブロックは強制的にディスクに書き出し、スーパーブロック (super block) を更新します。 |
|
指定されたファイルを逆順にして連結します。 |
|
指定されたファイルの最終の10行 (あるいは指定された行数) を表示します。 |
|
標準入力を読み込んで、標準出力と指定ファイルの双方に出力します。 |
|
ファイルタイプの比較やチェックを行います。 |
|
指定時間内だけコマンドを実行します。 |
|
ファイルのタイムスタンプを更新します。 そのファイルに対するアクセス時刻、更新時刻を現在時刻にするものです。 そのファイルが存在しなかった場合はゼロバイトのファイルを新規生成します。 |
|
標準入力から読み込んだ文字列に対して、変換、圧縮、削除を行います。 |
|
何も行わず処理に成功します。これは常に成功を意味するステータスコードを返して終了します。 |
|
ファイルを指定されたサイズに縮小または拡張します。 |
|
トポロジカルソート (topological sort) を行います。 指定されたファイルの部分的な順序に従って並び替えリストを出力します。 |
|
標準入力に接続された端末のファイル名を表示します。 |
|
システム情報を表示します。 |
|
空白文字をタブ文字に変換します。 |
|
連続する同一行を一行のみ残して削除します。 |
|
指定されたファイルを削除します。 |
|
現在ログインしているユーザー名を表示します。 |
|
ls -l と同じ。 |
|
指定されたファイルの行数、単語数、バイト数を表示します。 複数ファイルが指定された場合はこれに加えて合計も出力します。 |
|
誰がログインしているかを表示します。 |
|
現在有効なユーザーIDに関連づいているユーザー名を表示します。 |
|
処理が停止されるまで繰り返して「y」または指定文字を出力します。 |
|
stdbuf が利用するライブラリ。 |
Check は C 言語に対してのユニットテストのフレームワークです。
Check をコンパイルするための準備をします。
./configure --prefix=/usr --disable-static
パッケージをビルドします。
make
コンパイルが終了しました。 テストスイートを実行する場合は、以下を実行します。
make check
パッケージをインストールします。
make docdir=/usr/share/doc/check-0.15.2 install
Diffutils パッケージはファイルやディレクトリの差分を表示するプログラムを提供します。
Diffutils をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルします。
make
ビルド結果をテストするなら以下を実行します。
make check
パッケージをインストールします。
make install
Gawk パッケージはテキストファイルを操作するプログラムを提供します。
まずは不要なファイルがインストールされないようにします。
sed -i 's/extras//' Makefile.in
Gawk をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルします。
make
コンパイル結果をテストするには以下を実行します。
make check
パッケージをインストールします。
make install
必要ならドキュメントをインストールします。
mkdir -pv /usr/share/doc/gawk-5.1.1 cp -v doc/{awkforai.txt,*.{eps,pdf,jpg}} /usr/share/doc/gawk-5.1.1
Findutils パッケージはファイル検索を行うプログラムを提供します。 このプログラムはディレクトリツリーを再帰的に検索したり、データベースの生成、保守、検索を行います。 (データベースによる検索は再帰的検索に比べて処理速度は速いものですが、データベースが最新のものに更新されていない場合は信頼できない結果となります。)
Findutils をコンパイルするための準備をします。
case $(uname -m) in i?86) TIME_T_32_BIT_OK=yes ./configure --prefix=/usr --localstatedir=/var/lib/locate ;; x86_64) ./configure --prefix=/usr --localstatedir=/var/lib/locate ;; esac
configure オプションの意味
この設定は 32 ビットシステム上でビルドする際に必要となります。
--localstatedir
locate
データベースの場所を FHS コンプライアンスに準拠するディレクトリ /var/lib/locate
に変更します。
パッケージをコンパイルします。
make
コンパイル結果をテストするなら以下を実行します。
chown -Rv tester . su tester -c "PATH=$PATH make check"
パッケージをインストールします。
make install
Groff パッケージはテキストを処理して整形するプログラムを提供します。
Groff はデフォルトの用紙サイズを設定する環境変数 PAGE
を参照します。 米国のユーザーであれば PAGE=letter
と設定するのが適当です。
その他のユーザーなら PAGE=A4
とするのが良いかもしれません。 このデフォルト用紙サイズはコンパイルにあたって設定されます。 「A4」なり「letter」なりの値は
/etc/papersize
ファイルにて設定することも可能です。
Groff をコンパイルするための準備をします。
PAGE=<paper_size>
./configure --prefix=/usr
このパッケージでは並行ビルドはサポートされていません。 パッケージをコンパイルします。
make -j1
このパッケージにテストスイートはありません。
パッケージをインストールします。
make install
troff のフォントファイルを読み込んで groff システムが利用する付加的なフォントメトリック情報を追加します。 |
|
groff と grops が利用するフォントファイルを生成します。 |
|
化学構造図 (chemical structure diagrams) を生成するための Groff プロセッサー。 |
|
troff の入力ファイル内に埋め込まれている記述式をコンパイルして troff が解釈できるコマンドとして変換します。 |
|
troff の EQN (数式) を、刈り込んだ (crop した) イメージに変換します。 |
|
groff、nroff、troff の入力ファイルを比較して、その差異を変更マークとして出力します。 |
|
lilypond 言語で書かれたシートミュージック (sheet music) を groff 言語に変換します。 |
|
groff プリプロセッサーであり groff ファイルへの perl コード追加を行います。 |
|
groff プリプロセッサーであり groff ファイルへの中国語発音 Pinyin 追加を行います。 |
|
grap ダイアグラムを、刈り込んだ (crop した) ビットマップイメージに変換します。 |
|
gremlin 図を表すファイルを処理するための groff プリプロセッサー。 |
|
TeX の dvi フォーマットを生成するための groff ドライバープログラム。 |
|
groff 文書整形システムのためのフロントエンド。 通常は troff プログラムを起動し、指定されたデバイスに適合したポストプロセッサーを呼び出します。 |
|
groff ファイルや man ページを X 上や TTY 端末上に表示します。 |
|
入力ファイルを読み込んで、印刷時には groff
コマンドオプションのどれが必要かを推定します。 コマンドオプションは |
|
Canon CAPSL プリンター (LBP-4 または LBP-8 シリーズのレーザープリンター) に対する groff ドライバープログラム。 |
|
HP LaserJet 4 プリンターに対しての PCL5 フォーマットを出力する groff ドライバープログラム。 |
|
GNU troff の出力を PDF に変換します。 |
|
GNU troff の出力を PostScript に変換します。 |
|
GNU troff の出力を、タイプライター風のデバイスに適した形式に変換します。 |
|
HP のタグ付けが行われたフォントメトリックファイルから groff -Tlj4 コマンドにて利用されるフォントファイルを生成します。 |
|
指定されたファイル内に示される参考文献データベース (bibliographic database) に対しての逆引きインデックス (inverted index) を生成します。 これは refer、lookbib、lkbib といったコマンドが利用します。 |
|
指定されたキーを用いて参考文献データベースを検索し、合致したすべての情報を表示します。 |
|
(標準入力が端末であれば) 標準エラー出力にプロンプトを表示して、標準入力から複数のキーワードを含んだ一行を読み込みます。 そして指定されたファイルにて示される参考文献データベース内に、そのキーワードが含まれるかどうかを検索します。 キーワードが含まれるものを標準出力に出力します。入力がなくなるまでこれを繰り返します。 |
|
groff 用の単純なプリプロセッサー。 |
|
数式を ASCII (American Standard Code for Information Interchange) 形式で出力します。 |
|
groff を利用して nroff コマンドをエミュレートするスクリプト。 |
|
groff 関連ラッパー。mom マクロによるファイルから PDF を生成します。 |
|
groff を利用して pdf 文書ファイルを生成します。 |
|
|
|
troff または TeX の入力ファイル内に埋め込まれた図の記述を、troff または TeX が処理できるコマンドの形式に変換します。 |
|
PIC ダイアグラムを、刈り込んだ (crop した) イメージに変換します。 |
|
GNU troff の出力を HTML に変換します。 |
|
入力ファイルのエンコーディングを GNU troff が取り扱うものに変換します。 |
|
GNU troff の出力を HTML に変換します。 |
|
ファイル内容を読み込んで、そのコピーを標準出力へ出力します。 ただし引用文を表す .[ と .] で囲まれた行、および引用文をどのように処理するかを示したコマンドを意味する .R1 と .R2 で囲まれた行は、コピーの対象としません。 |
|
roff ファイルを DVI フォーマットに変換します。 |
|
roff ファイルを HTML フォーマットに変換します。 |
|
roff ファイルを PDF フォーマットに変換します。 |
|
roff ファイルを ps ファイルに変換します。 |
|
roff ファイルをテキストファイルに変換します。 |
|
roff ファイルを他のフォーマットに変換します。 |
|
入力ファイルを読み込んで .so ファイル の形式で記述されている行を、記述されている ファイル だけに置き換えます。 |
|
troff 入力ファイル内に埋め込まれた表の記述を troff が処理できるコマンドの形式に変換します。 |
|
コマンド groff -Tdvi を使ってフォントファイルを生成します。 |
|
Unix の troff コマンドと高い互換性を持ちます。 通常は groff コマンドを用いて本コマンドが起動されます。 groff コマンドは、プリプロセッサー、ポストプロセッサーを、適切な順で適切なオプションをつけて起動します。 |
GRUB パッケージは GRand Unified Bootloader を提供します。
システムが UEFI をサポートしていて、これを使って LFS を起動しようとする場合は、LFS における本パッケージは省略することができます。 その場合は本章の終わりに、BLFS ページ に従って UEFI 対応の GRUB (およびその依存パッケージ) をインストールしてください。
GRUB をコンパイルするための準備をします。
./configure --prefix=/usr \ --sysconfdir=/etc \ --disable-efiemu \ --disable-werror
configure オプションの意味
--disable-werror
本オプションは、最新の flex によって警告が出力されても、ビルドを成功させるために指定します。
--disable-efiemu
このオプションは LFS にとって不要な機能やテストプログラムをビルドしないようにします。
パッケージをコンパイルします。
make
本パッケージのテストスイートの利用はお勧めできません。 テストのほとんどが、限定されている今の LFS 環境内では利用できないパッケージに依存しています。 それでもテストを行うのであれば、make check を実行します。
パッケージをインストールします。
make install mv -v /etc/bash_completion.d/grub /usr/share/bash-completion/completions
GRUB を使ってシステムのブート起動設定を行う方法については 「GRUB を用いたブートプロセスの設定」で説明しています。
grub-install に対するヘルパープログラム。 |
|
環境ブロック (environment block) を編集するツール。 |
|
FILE が指定されたタイプであるかどうかをチェックします。 |
|
ファイルシステムドライバーをデバッグするツール。 |
|
32 ビットおよび 64 ビットの実行バイナリを Apple ユニバーサル形式に結合します。 |
|
指定したドライブに GRUB をインストールします。 |
|
xkb レイアウトを GRUB が認識できる他の書式に変換するスクリプト。 |
|
HFS または HFS+ ファイルに対する Mac 風の bless |
|
GRUB Legacy の |
|
GRUB の設定ファイルを生成します。 |
|
GRUB のブートイメージ (bootable image) を生成します。 |
|
GRUB のキーボードレイアウトファイルを生成します。 |
|
GRUB のネットブートディレクトリを生成します。 |
|
ブートメニューにて利用する、PBKDF2 により暗号化されたパスワードを生成します。 |
|
システムのパスをルートからの相対パスとします。 |
|
フロッピーディスクや CDROM/DVD 用の GRUB のブートイメージを生成します。 |
|
スタンドアロンイメージを生成します。 |
|
GRUB デバイスのパスを出力するヘルパープログラム。 |
|
指定されたパスやデバイスに対するデバイス情報を検証 (probe) します。 |
|
デフォルトのブートメニューを設定します。 これは次にブートした時だけ有効なものです。 |
|
Apple Mac に対して Apple .disk_label を提供します。 |
|
GRUB の設定スクリプトにおける文法をチェックします。 |
|
デフォルトのブートメニューを設定します。 |
|
grub-setup に対するヘルパープログラム。 |
|
syslinux の設定ファイルを grub.cfg フォーマットに変換します。 |
Gzip パッケージはファイルの圧縮、伸長 (解凍) を行うプログラムを提供します。
Gzip をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルします。
make
コンパイル結果をテストするには以下を実行します。
make check
パッケージをインストールします。
make install
gzip により圧縮されたファイルを解凍します。 |
|
自動解凍形式の実行ファイルを生成します。 |
|
Lempel-Ziv (LZ77) 方式により指定されたファイルを圧縮します。 |
|
圧縮されたファイルを解凍します。 |
|
gzip により圧縮されたファイルを解凍して標準出力へ出力します。 |
|
gzip により圧縮されたファイルに対して cmp を実行します。 |
|
gzip により圧縮されたファイルに対して diff を実行します。 |
|
gzip により圧縮されたファイルに対して egrep を実行します。 |
|
gzip により圧縮されたファイルに対して fgrep を実行します。 |
|
指定されたファイルが gzip により圧縮されている場合に、強制的に拡張子 |
|
gzip により圧縮されたファイルに対して grep を実行します。 |
|
gzip により圧縮されたファイルに対して less を実行します。 |
|
gzip により圧縮されたファイルに対して more を実行します。 |
|
compress
フォーマットの圧縮ファイルを gzip
フォーマットのファイルとして再圧縮します。 つまり |
IPRoute2 パッケージは IPV4 ベースの基本的または応用的ネットワーク制御を行うプログラムを提供します。
本パッケージにて提供している arpd プログラムは LFS では取り扱わない Berkeley DB に依存しています。 したがって arpd プログラムはインストールしません。 ただし arpd プログラムに対応するディレクトリや man ページはインストールされてしまいます。 これをインストールしないように、以下のコマンドを実行します。 arpd プログラムを必要とする場合は BLFS ブックの https://www.linuxfromscratch.org/blfs/view/stable-systemd/server/db.html#db に示される Berkeley DB の構築手順に従ってください。
sed -i /ARPD/d Makefile rm -fv man/man8/arpd.8
パッケージをコンパイルします。
make NETNS_RUN_DIR=/run/netns
本パッケージには有効なテストスイートはありません。
パッケージをインストールします。
make SBINDIR=/usr/sbin install
必要な場合はドキュメントをインストールします。
mkdir -pv /usr/share/doc/iproute2-5.19.0 cp -v COPYING README* /usr/share/doc/iproute2-5.19.0
ネットワークブリッジを設定します。 |
|
接続ステータスの表示ユーティリティ。 |
|
汎用的な netlink ユーティリティフロントエンド。 |
|
ip コマンドに対するシェルスクリプトラッパー。 http://www.skbuff.net/iputils/ にて提供されている iputils パッケージの arping プログラムと rdisk プログラムを利用します。 |
|
インターフェースの統計情報を表示します。 インターフェースによって送受信されたパケット量が示されます。 |
|
主となる実行モジュールで、複数の機能性を持ちます。
ip link ip addr はアドレスとその属性を参照し、新しいアドレスの追加、古いアドレスの削除を行います。 ip neighbor は隣接ルーター (neighbor) の割り当てや属性を参照し、隣接ルーターの項目追加や古いものの削除を行います。 ip rule はルーティングポリシー (routing policy) を参照し、変更を行います。 ip route はルーティングテーブル (routing table) を参照し、ルーティングルール (routing table rule) を変更します。 ip tunnel は IP トンネル (IP tunnel) やその属性を参照し、変更を行います。 ip maddr はマルチキャストアドレス (multicast address) やその属性を参照し、変更を行います。 ip mroute はマルチキャストルーティング (multicast routing) の設定、変更、削除を行います。 ip monitor はデバイスの状態、アドレス、ルートを継続的に監視します。 |
|
Linux のネットワーク統計情報を提供します。 これはかつての rtstat プログラムを汎用的に機能充足を図ったプログラムです。 |
|
ネットワーク統計情報を表示します。 |
|
ip route のコンポーネント。 これはルーティングテーブルをクリアします。 |
|
ip route のコンポーネント。 これはルーティングテーブルの一覧を表示します。 |
|
|
|
ルート監視ユーティリティー。 |
|
ip -o コマンドにより出力される内容を読みやすい形に戻します。 |
|
ルートステータスの表示ユーティリティー。 |
|
netstat コマンドと同じ。 アクティブな接続を表示します。 |
|
トラフィック制御プログラム (Traffic Controlling Executable)。 これは QOS (Quality Of Service) と COS (Class Of Service) を実装するプログラムです。 tc qdisc はキューイング規則 (queueing discipline) の設定を行います。 tc class はキューイング規則スケジューリング (queueing discipline scheduling) に基づくクラスの設定を行います。 tc estimator はネットワークフローを見積もります。 tc filter は、QOS/COS パケットのフィルタリング設定を行います。 tc policy は、QOS/COS ポリシーの設定を行います。 |
Kbd パッケージは、キーテーブル (key-table) ファイル、コンソールフォント、キーボードユーティリティを提供します。
バックスペース (backspace) キーとデリート (delete) キーは Kbd パッケージのキーマップ内では一貫した定義にはなっていません。 以下のパッチは i386 用のキーマップについてその問題を解消します。
patch -Np1 -i ../kbd-2.5.1-backspace-1.patch
パッチを当てればバックスペースキーの文字コードは 127 となり、デリートキーはよく知られたエスケープコードを生成することになります。
不要なプログラム resizecons とその man ページを削除します。 (今はもう存在しない svgalib がビデオモードファイルを提供するために利用していたものであり、普通は setfont コマンドがコンソールサイズを適切に設定します。)
sed -i '/RESIZECONS_PROGS=/s/yes/no/' configure sed -i 's/resizecons.8 //' docs/man/man8/Makefile.in
Kbd をコンパイルするための準備をします。
./configure --prefix=/usr --disable-vlock
configure オプションの意味
--disable-vlock
このオプションは vlock ユーティリティーをビルドしないようにします。 そのユーティリティーは PAM ライブラリが必要ですが、chroot 環境では利用することができません。
パッケージをコンパイルします。
make
ビルド結果をテストする場合は以下を実行します。
make check
パッケージをインストールします。
make install
ベラルーシ語のような言語において Kbd パッケージは正しいキーマップを提供せず、ISO-8859-5 エンコーディングで CP1251 キーマップであるものとして扱われます。 そのような言語ユーザーは個別に正しいキーマップをダウンロードして設定する必要があります。
必要ならドキュメントをインストールします。
mkdir -pv /usr/share/doc/kbd-2.5.1 cp -R -v docs/doc/* /usr/share/doc/kbd-2.5.1
現在表示されている仮想端末を切り替えます。 |
|
未使用の仮想端末への割り当てを開放します。 |
|
キーボード変換テーブル (keyboard translation table) の情報をダンプします。 |
|
アクティブな仮想端末数を表示します。 |
|
カーネルのスキャンコード-キーコード (scancode-to-keycode) マッピングテーブルを表示します。 |
|
コンソール状態に関しての情報を取得します。 |
|
キーボードモードの表示または設定を行います。 |
|
キーボードのリピート速度 (repeat rate) と遅延時間 (delay rate) を設定します。 |
|
キーボード変換テーブル (keyboard translation tables) をロードします。 |
|
カーネルのユニコード-フォント (unicode-to-font) マッピングテーブルをロードします。 |
|
かつてのプログラムです。 これはユーザー定義の文字マッピングテーブルをコンソールドライバーにロードするために利用します。 現在では setfont を利用します。 |
|
新しい仮想端末 (virtual terminal; VT) 上でプログラムを起動します。 |
|
Unicode キャラクターテーブルをコンソールフォントに追加します。 |
|
コンソールフォントから埋め込まれた Unicode キャラクターテーブルを抽出します。 |
|
コンソールフォントから埋め込められた Unicode キャラクターテーブルを削除します。 |
|
コンソールフォント用のユニコード文字テーブルを取り扱います。 |
|
EGA (Enhanced Graphic Adapter) フォントや VGA (Video Graphics Array) フォントを変更します。 |
|
カーネルのスキャンコード-キーコード (scancode-to-keycode) マッピングテーブルの項目をロードします。 キーボード上に特殊キーがある場合に利用します。 |
|
キーボードフラグや LED (Light Emitting Diode) を設定します。 |
|
キーボードのメタキー (meta-key) 設定を定義します。 |
|
仮想端末すべてに対してコンソールのカラーマップを設定します。 |
|
現在設定されている EGA/VGA コンソールスクリーンフォントを表示します。 |
|
キーボード上にて押下されたキーのスキャンコード、キーコード、ASCII コードを表示します。 |
|
キーボードとコンソールをユニコードモードにします。 キーマップファイルが ISO-8859-1 エンコーディングで書かれている場合にのみこれを利用します。 他のエンコーディングの場合、このプログラムの出力結果は正しいものになりません。 |
|
キーボードとコンソールをユニコードモードから戻します。 |
Libpipeline パッケージは、サブプロセスのパイプラインを柔軟かつ便利に取り扱うライブラリを提供します。
Libpipeline をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルします。
make
ビルド結果をテストする場合は以下を実行します。
make check
パッケージをインストールします。
make install
Make パッケージは、対象となるパッケージのソースファイルを用いて、実行モジュールやそれ以外のファイルの生成、管理を行うプログラムを提供します。
Make をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルします。
make
コンパイル結果をテストするには以下を実行します。
make check
パッケージをインストールします。
make install
Patch パッケージは「パッチ」ファイルを適用することにより、ファイルの修正、生成を行うプログラムを提供します。 「パッチ」ファイルは diff プログラムにより生成されます。
Patch をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルします。
make
コンパイル結果をテストするには以下を実行します。
make check
パッケージをインストールします。
make install
Tar パッケージは tar アーカイブの生成を行うとともに、アーカイブ操作に関する多くの処理を提供します。 Tar はすでに生成されているアーカイブからファイルを抽出したり、ファイルを追加したりします。 あるいはすでに保存されているファイルを更新したり一覧を表示したりします。
Tar をコンパイルするための準備をします。
FORCE_UNSAFE_CONFIGURE=1 \ ./configure --prefix=/usr
configure オプションの意味
FORCE_UNSAFE_CONFIGURE=1
このオプションは、mknod
に対するテストを
root
ユーザーにて実行するようにします。
一般にこのテストを root
ユーザーで実行することは危険なこととされますが、ここでは部分的にビルドしたシステムでテストするものであるため、オーバーライドすることで支障はありません。
パッケージをコンパイルします。
make
コンパイル結果をテストするために以下を実行します。
make check
テストの 1 つ capabilities: binary store/restore は、LFS が selinux を含んでいないため、実行に失敗します。 ただし LFS ビルドに利用するファイルシステム上において、ホストカーネルが拡張属性をサポートしていない場合、このテストはスキップされます。
パッケージをインストールします。
make install make -C doc install-html docdir=/usr/share/doc/tar-1.34
Texinfo パッケージは info ページへの読み書き、変換を行うプログラムを提供します。
Texinfo をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルします。
make
コンパイル結果をテストするには以下を実行します。
make check
パッケージをインストールします。
make install
必要なら TeX システムに属するコンポーネント類をインストールします。
make TEXMF=/usr/share/texmf install-tex
make パラメーターの意味
TEXMF=/usr/share/texmf
Makefile 変数である TEXMF
に TeX
ツリーのルートディレクトリを設定します。 これは後に TeX パッケージをインストールするための準備です。
ドキュメントシステム Info は、 メニュー項目の一覧を単純なテキストファイルに保持しています。 そのファイルは
/usr/share/info/dir
にあります。
残念ながら数々のパッケージの Makefile は、既にインストールされている info
ページとの同期を取る処理を行わない場合があります。 /usr/share/info/dir
の再生成を必要とするなら、以下のコマンドを実行してこれを実現します。
pushd /usr/share/info rm -v dir for f in * do install-info $f dir 2>/dev/null done popd
info ページを見るために利用します。 これは man ページに似ていますが、単に利用可能なコマンドラインオプションを説明するだけのものではなく、おそらくはもっと充実しています。 例えば man bison と info bison を比較してみてください。 |
|
info ページをインストールします。 info 索引ファイルにある索引項目も更新します。 |
|
指定された Texinfo ソースファイルを Info ページ、プレーンテキスト、HTML ファイルに変換します。 |
|
指定された Texinfo ドキュメントファイルを PDF (Portable Document Format) ファイルに変換します。 |
|
Pod フォーマットを Texinfo フォーマットに変換します。 |
|
Texinfo のソースファイルを他のさまざまなフォーマットに変換します。 |
|
指定された Texinfo ドキュメントファイルを、デバイスに依存しない印刷可能なファイルに変換します。 |
|
指定された Texinfo ドキュメントファイルを PDF (Portable Document Format) ファイルに変換します。 |
|
Texinfo 索引ファイルの並び替えを行います。 |
Vim パッケージは強力なテキストエディターを提供します。
もし Emacs、Joe、Nano など他のエディターを用いたい場合は https://www.linuxfromscratch.org/blfs/view/stable-systemd/postlfs/editors.html に示される手順に従ってインストールしてください。
設定ファイル vimrc
がインストールされるデフォルトディレクトリを /etc
に変更します。
echo '#define SYS_VIMRC_FILE "/etc/vimrc"' >> src/feature.h
vim をコンパイルするための準備をします。
./configure --prefix=/usr
パッケージをコンパイルします。
make
コンパイル結果をテストするために、tester
ユーザーがソースツリーに書き込みできるようにします。
chown -Rv tester .
tester
ユーザーによりテストを実行します。
su tester -c "LANG=en_US.UTF-8 make -j1 test" &> vim-test.log
このテストスイートは数多くのバイナリデータを端末画面上に出力します。 これは端末画面の設定によっては問題を引き起こします。 これを避けるには、上に示すように出力をリダイレクトしてログファイルに出力するようにしてください。 テストが成功すれば、ログファイルの最後に "ALL DONE" と表示されます。
パッケージをインストールします。
make install
たいていのユーザーは vim ではなく vi を使うようです。 vi を入力しても vim が実行されるように、実行モジュールに対するシンボリックリンクを作成します。 さらに指定された言語による man ページへのシンボリックリンクも作成します。
ln -sv vim /usr/bin/vi for L in /usr/share/man/{,*/}man1/vim.1; do ln -sv vim.1 $(dirname $L)/vi.1 done
デフォルトでは vim のドキュメントが /usr/share/vim
にインストールされます。
以下のようなシンボリックリンクを生成することで /usr/share/doc/vim-9.0.0228
へアクセスしてもドキュメントが参照できるようにし、他のパッケージが配置するドキュメントの場所と整合を取ります。
ln -sv ../vim/vim90/doc /usr/share/doc/vim-9.0.0228
LFS システムに対して X ウィンドウシステムをインストールする場合 X のインストールの後で vim を再コンパイルする必要があります。 vim には GUI 版があり X や他のライブラリがインストールされていて 初めて構築できるためです。 この作業の詳細については vim のドキュメントと BLFS ブックの https://www.linuxfromscratch.org/blfs/view/stable-systemd/postlfs/vim.html に示されている Vim のインストール説明のページを参照してください。
デフォルトで vim は vi 非互換モード (vi-incompatible mode) で起動します。 他のエディターを使ってきたユーザーにとっては、よく分からないものかもしれません。 以下の設定における「nocompatible」(非互換) は、Vi の新しい機能を利用することを意味しています。 もし「compatible」(互換) モードに変更したい場合は、この設定ファイルの冒頭にて行っておくことが必要です。 このモード設定は他の設定を置き換えるものとなることから、まず初めに行っておかなければならないものだからです。 以下のコマンドを実行して vim の設定ファイルを生成します。
cat > /etc/vimrc << "EOF"
" Begin /etc/vimrc
" Ensure defaults are set before customizing settings, not after
source $VIMRUNTIME/defaults.vim
let skip_defaults_vim=1
set nocompatible
set backspace=2
set mouse=
syntax on
if (&term == "xterm") || (&term == "putty")
set background=dark
endif
" End /etc/vimrc
EOF
set nocompatible
と設定しておくと vi 互換モードでの動作に比べて有用な動作となります。(これがデフォルトになっています。)
その設定の記述から「no」の文字を取り除けば、旧来の vi コマンドの動作となります。 set backspace=2
を設定しておくと、行を超えてもバックスペースキーによる編集が可能となります。
またインデントが自動的に行われ、コマンド起動時には自動的に挿入モードとなります。 syntax on
パラメーターを指定すれば vim
の文法ハイライト (syntax highlighting) 機能が有効になります。 set mouse=
を指定すると chroot
環境やリモート接続時であってもマウスによるテキスト選択が適切になります。 最後にある if 文は、set background=dark
を指定した場合に、特定の端末エミュレーター上において vim
が背景色を誤って認識しないようにするためのものです。
エミュレーターの背景色が黒色であった場合に、より適切なハイライトが実現できます。
この他に利用できるオプションについては、以下のコマンドを実行することで出力される説明を参照してください。
vim -c ':options'
vim がインストールするスペルファイル (spell files) はデフォルトでは英語に対するものだけです。
必要とする言語のスペルファイルをインストールするなら ftp://ftp.vim.org/pub/vim/runtime/spell/
から、特定の言語、エンコーディングによる *.spl
ファイル、またオプションとして *.sug
ファイルをダウンロードしてください。 そしてそれらのファイルを /usr/share/vim/vim90/spell/
ディレクトリに保存してください。
スペルファイルを利用するには /etc/vimrc
ファイルにて、例えば以下のような設定が必要になります。
set spelllang=en,ru
set spell
詳しくは、上で説明した URL にて提供されている README ファイルを参照してください。
vim を ex モードで起動します。 |
|
view の機能限定版。 シェルは起動できず、サスペンドも行うことはできません。 |
|
vim の機能限定版。 シェルは起動できず、サスペンドも行うことはできません。 |
|
vim へのリンク。 |
|
vim を読み込み専用モード (read-only mode) で起動します。 |
|
エディター。 |
|
vim により、同一ファイルにおける 2 つまたは 3 つの版を同時に編集し、差異を表示します。 |
|
vim の基本的なキー操作とコマンドについて教えてくれます。 |
|
指定されたファイルの内容を 16進数ダンプとして変換します。 逆の変換も行うことができるため、バイナリパッチにも利用されます。 |
MarkupSafe は、XML/HTML/XHTML マークアップセーフな文字列を実装する Python モジュールです。
以下のコマンドを実行して MarkupSafe をコンパイルします。
pip3 wheel -w dist --no-build-isolation --no-deps $PWD
このパッケージにテストスイートはありません。
パッケージをインストールします。
pip3 install --no-index --no-user --find-links dist Markupsafe
Jinja2 は、Python の簡単なテンプレート言語を実装する Python モジュールです。
パッケージをビルドするために以下を実行します。
pip3 wheel -w dist --no-build-isolation --no-deps $PWD
パッケージをインストールします。
pip3 install --no-index --no-user --find-links dist Jinja2
systemd パッケージは、システムの起動、稼動、終了の制御を行うプログラムを提供します。
はじめに glibc-2.36 において発生する問題を修正します。
patch -Np1 -i ../systemd-251-glibc_2.36_fix-1.patch
デフォルトの udev ルールから、不要な 2 つのグループ render
と sgx
を削除します。
sed -i -e 's/GROUP="render"/GROUP="video"/' \ -e 's/GROUP="sgx", //' rules.d/50-udev-default.rules.in
systemd をコンパイルするための準備をします。
mkdir -p build cd build meson --prefix=/usr \ --buildtype=release \ -Ddefault-dnssec=no \ -Dfirstboot=false \ -Dinstall-tests=false \ -Dldconfig=false \ -Dsysusers=false \ -Drpmmacrosdir=no \ -Dhomed=false \ -Duserdb=false \ -Dman=false \ -Dmode=release \ -Dpamconfdir=no \ -Ddocdir=/usr/share/doc/systemd-251 \ ..
meson オプションの意味
--buildtype=release
本スイッチは、デフォルトのビルドタイプ (「debug」) をオーバーライドします。 そのままにしておくと、最適化されていない実行モジュールが生成されるためです。
-Ddefault-dnssec=no
本スイッチは、実験的な DNSSEC サポートを無効にします。
-Dfirstboot=false
本スイッチは、systemd サービスを、システムの初回構築用としてインストールしないようにします。 LFS ではすべて手作業で行うため、この機能が必要ないからです。
-Dinstall-tests=false
本スイッチはコンパイルされたテストをインストールしないようにします。
-Dldconfig=false
本スイッチは、システム起動時に ldconfig を実行するような systemd ユニットはインストールしないようにします。 LFS のようにソースから作り出すディストリビューションにとっては無用なものであり、起動時間も長くなります。 もし必要であれば本スイッチを除いてください。
-Dsysusers=false
本スイッチは、システム起動初期に /etc/group
ファイルと /etc/passwd
ファイルを設定する systemd
サービスをインストールしないようにします。 この二つのファイルは前章にて生成済です。 LFS
システム上におけるこのデーモンは、ユーザーアカウントを手動で生成するまでは、利用することはできません。
-Drpmmacrosdir=no
本スイッチは systemd において利用される RPM マクロをインストールしないようにします。 LFS では RPM をサポートしていないためです。
-D{userdb,homed}=false
LFS が取り扱う範囲にそぐわない依存関係を持ったデーモンを削除します。
-Dman=false
man ページを生成することで発生する追加パッケージの導入を行わないようにします。 systemd の man ページは、後ほど生成済みの tarball を使ってインストールすることにします。
-Dmode=release
アップストリームにおいて試験的機能とみなされている機能を無効にします。
-Dpamconfdir=no
PAM 設定は LFS 上では機能しないため、これをインストールしないようにします。
パッケージをコンパイルします。
ninja
パッケージをインストールします。
ninja install
man ページをインストールします。
tar -xf ../../systemd-man-pages-251.tar.xz --strip-components=1 -C /usr/share/man
systemd-journald に対して必要となる
/etc/machine-id
ファイルを生成します。
systemd-machine-id-setup
基本的なターゲット構造を設定します。
systemctl preset-all
バイナリディストリビューションの更新サービスを無効にします。 ソースからのビルドを行う単純な Linux システムでは不要だからです 有効化されても設定が行われていない場合には、エラーが出力されます。
systemctl disable systemd-sysupdate
D-Bus のバスを監視するために用います。 |
|
systemd journal よりコアダンプを抽出します。 |
|
普通は shutdown にオプション
|
|
システムのホスト名および関連設定を確認し変更します。 |
|
カーネルがハードウェアを初期化する際に起動される最初のプロセスであり、この後の起動処理を担い、設定ファイルに応じたブートプロセスと他の全てのプロセスを起動します。つまり systemd を起動するということです。 |
|
Systemd のジャーナルの内容を確認します。 |
|
カーネルや initramfs イメージを /boot ディレクトリに対して追加、削除します。 |
|
システムロケールやキーボードレイアウト設定を確認し変更します。 |
|
Systemd のログインマネージャーの状態を確認し制御します。 |
|
Systemd の仮想マシンとコンテナー登録マネージャー (Container Registration Manager) の状態を確認し制御します。 |
|
systemd-netword から見えるネットワークリンクの状態を確認 (introspect) し設定します。 |
|
systemd の Out Of Memory デーモンを制御します。 |
|
ローカルシステムにおいてポータブルサービスのアタッチ、デタッチを行います。 |
|
カーネルに対してシステム停止を指示し、コンピューターの電源を落とします。(halt参照) |
|
カーネルに対してシステム再起動を指示します。(halt参照) |
|
systemd-resolved に対する DNS サーバーやドメイン設定を登録します。 |
|
ネットワーク名前解決マネージャーに対して制御コマンドを送信します。 あるいはドメイン名、IPv4、IPv6 アドレス、DNS レコードやサービスなどを解決します。 |
|
現時点とその直前のランレベルを表示します。 最新のランレベルは |
|
すべてのプロセスとすべてのログインユーザーへの通知を行なった上で、システムを安全に停止します。 |
|
Systemd システムとサービスマネージャーの状態について確認し制御します。 |
|
現在のシステム起動において、起動処理パフォーマンスを決定します。 また問題のある systemd ユニットを特定します。 |
|
コマンドラインから指定された質問文を用いて、システムパスワードやユーザーのパスフレーズを確認します。 |
|
systemd journal に対してプロセスの STDOUT と STDERR に接続します。 |
|
指定された Linux コントロールグループ (control group) の階層を再帰的に表示します。 |
|
最上位のローカル Linux コントロールグループ (control group) を表示し、CPU、メモリ、ディスクI/Oロードの並びにより示します。 |
|
資格情報を表示し処理します。 |
|
|
|
システムが仮想化環境で動作しているかどうかを検出し、それに応じて udev を調整します。 |
|
OS ディスクイメージの調査に用いられます。 |
|
systemd ユニット名での文字エスケープを行います。 |
|
ハードウェアデータベース (hwdb) を管理します。 |
|
id128 文字列を生成し表示します。 |
|
システム停止、休止、アイドル禁止ロックを行うプログラムを実行します。 プロセスが正常起動するまでは、システムシャットダウンのような処理は行いません。 |
|
システムインストールツールがマシンIDを初期化するために利用します。 このマシンIDは
|
|
ディスクの一時的あるいは自動マウントを行ないます。 |
|
init システムに対してステータス変更が発生したことを通知するデーモンスクリプトが利用します。 |
|
軽量な名前空間コンテナー (light-weight namepspace container) においてコマンドや OS の実行に用いられます。 |
|
システムパスやユーザーパスを検索します。 |
|
systemd が OS イメージ内(たとえばコンテナーなど)で用いられている場合に、パーティションテーブルに対してパーティションの拡張や追加を行うために用いられます。 |
|
ドメイン名、IPV4 と IPv6 アドレス、DNSリソースレコード、サービスの名前解決を行います。 |
|
一時的な .service ユニットや .scope ユニットを生成および起動し、その指定コマンドを実行します。 これは systemd ユニットの検証を行うことができます。 |
|
ソケットデバイスの情報を読み取って、ソケットに対するコネクション上にてプロセスを起動します。 |
|
システム拡張イメージを有効にします。 |
|
|
|
マウントポイントをアンマウントします。 |
|
未定となっている Systemd のパスワード変更指示の一覧を表示し処理します。 |
|
init コマンドに対してランレベルを何にするかを指示します。 |
|
システムクロックとその設定を確認し変更します。 |
|
汎用的な udev 管理ツール。 udevd デーモンの制御、Udev データベースデータの提供、uevent の監視、uevent の完了までの待機、udev 設定のテスト、指定デバイスに対する uevent の起動、といったことを行います。 |
|
主となる systemd ユーティリティライブラリ。 |
|
Udev デバイス情報にアクセスするためのライブラリ。 |
D-Bus はメッセージバスシステムであり、アプリケーションから他のアプリケーションへの通信を容易に行う方法を提供します。 D-Bus にはシステムデーモン (例えば "新たなハードウェアデバイスが追加されました" や "プリンターキューが変更されました" といったイベント) やログインユーザーごとのセッションデーモン (ユーザーアプリケーション間で必要な一般的なIPC) があります。 またメッセージバスは、一般的な1対1によるメッセージ送受信のフレームワーク上にビルドされます。 これは二つのアプリケーション間にて (メッセージバスデーモンを介さずに) 直接通信するために利用されます。
D-Bus をコンパイルするための準備をします。
./configure --prefix=/usr \ --sysconfdir=/etc \ --localstatedir=/var \ --runstatedir=/run \ --disable-static \ --disable-doxygen-docs \ --disable-xml-docs \ --docdir=/usr/share/doc/dbus-1.14.0 \ --with-system-socket=/run/dbus/system_bus_socket
configure オプションの意味
--runstatedir=/run
と
--with-system-socket=/run/dbus/system_bus_socket
これは PID ファイルとシステムバスソケットの場所を設定するものであり、かつての /var/run
ではなく /run
とします。
パッケージをコンパイルします。
make
本パッケージにはテストスイートがあります。 ただし実行するためには LFS には含まれていないパッケージをいくつか必要とします。 テストの実行方法については https://www.linuxfromscratch.org/blfs/view/stable-systemd/general/dbus.html に示されています。
パッケージをインストールします。
make install
シンボリックリンクを生成します。 D-Bus と systemd が同一の machine-id
ファイルを利用できるようにするためです。
ln -sfv /etc/machine-id /var/lib/dbus
ディレクトリ内に取り残されたソケットを削除します。 |
|
D-Bus メッセージバスデーモン。 |
|
シェルスクリプトから dbus-daemon を起動します。 |
|
D-Bus メッセージバスを通じたメッセージ送信を監視します。 |
|
シェルスクリプトから dbus-daemon のセッションバスインスタンスを起動します。 そしてそのセッションにて指定されたプログラムを起動します。 |
|
D-Bus メッセージバスにメッセージを送ります。 |
|
D-Bus のテストを補助するツールです。 |
|
D-Bus のセッションサービスに対して設定される環境変数を更新します。 |
|
ユニーク ID を生成します。 |
|
D-Bus メッセージバスとの通信を行う API 関数を提供します。 |
Man-DB パッケージは man ページを検索したり表示したりするプログラムを提供します。
Man-DB をコンパイルするための準備をします。
./configure --prefix=/usr \ --docdir=/usr/share/doc/man-db-2.10.2 \ --sysconfdir=/etc \ --disable-setuid \ --enable-cache-owner=bin \ --with-browser=/usr/bin/lynx \ --with-vgrind=/usr/bin/vgrind \ --with-grap=/usr/bin/grap
configure オプションの意味
--disable-setuid
これは man
プログラムが man
ユーザーに対して
setuid を実行しないようにします。
--enable-cache-owner=bin
システムワイドなキャッシュファイルの所有ユーザーを bin
とします。
--with-...
この三つのオプションはデフォルトで利用するプログラムを指定します。 lynx はテキストベースの Web ブラウザーです。 (BLFS でのインストール手順を参照してください。) vgrind はプログラムソースを Groff の入力形式に変換します。 grap は Groff 文書においてグラフを組版するために利用します。 vgrind と grap は man ページを見るだけであれば必要ありません。 これらは LFS や BLFS には含まれません。 もし利用したい場合は LFS の構築を終えた後に自分でインストールしてください。
パッケージをコンパイルします。
make
コンパイル結果をテストするには以下を実行します。
make check
パッケージをインストールします。
make install
以下に示す表は /usr/share/man/<ll>
配下にインストールされる man
ページとそのエンコーディングを示します。 Man-DB は man ページが UTF-8
エンコーディングかどうかを正しく認識します。
表8.1 8 ビット man ページのキャラクターエンコーディング
言語 (コード) | エンコーディング | 言語 (コード) | エンコーディング |
---|---|---|---|
デンマーク語 (da) | ISO-8859-1 | クロアチア語 (hr) | ISO-8859-2 |
ドイツ語 (de) | ISO-8859-1 | ハンガリー語 (hu) | ISO-8859-2 |
英語 (en) | ISO-8859-1 | 日本語 (ja) | EUC-JP |
スペイン語 (es) | ISO-8859-1 | 韓国語 (ko) | EUC-KR |
エストニア語 (et) | ISO-8859-1 | リトアニア語 (lt) | ISO-8859-13 |
フィンランド語 (fi) | ISO-8859-1 | ラトビア語 (lv) | ISO-8859-13 |
フランス語 (fr) | ISO-8859-1 | マケドニア語 (mk) | ISO-8859-5 |
アイルランド語 (ga) | ISO-8859-1 | ポーランド語 (pl) | ISO-8859-2 |
ガリシア語 (gl) | ISO-8859-1 | ルーマニア語 (ro) | ISO-8859-2 |
インドネシア語 (id) | ISO-8859-1 | ギリシア語 (el) | ISO-8859-7 |
アイスランド語 (is) | ISO-8859-1 | スロバキア語 (sk) | ISO-8859-2 |
イタリア語 (it) | ISO-8859-1 | スロベニア語 (sl) | ISO-8859-2 |
ノルウェー語 ブークモール (Norwegian Bokmal; nb) | ISO-8859-1 | セルビア Latin (sr@latin) | ISO-8859-2 |
オランダ語 (nl) | ISO-8859-1 | セルビア語 (sr) | ISO-8859-5 |
ノルウェー語 ニーノシュク (Norwegian Nynorsk; nn) | ISO-8859-1 | トルコ語 (tr) | ISO-8859-9 |
ノルウェー語 (no) | ISO-8859-1 | ウクライナ語 (uk) | KOI8-U |
ポルトガル語 (pt) | ISO-8859-1 | ベトナム語 (vi) | TCVN5712-1 |
スウェーデン語 (sv) | ISO-8859-1 | 中国語 簡体字 (Simplified Chinese) (zh_CN) | GBK |
ベラルーシ語 (be) | CP1251 | 中国語 簡体字 (Simplified Chinese), シンガポール (zh_SG) | GBK |
ブルガリア語 (bg) | CP1251 | 中国語 繁体字 (Traditional Chinese), 香港 (zh_HK) | BIG5HKSCS |
チェコ語 (cs) | ISO-8859-2 | 中国語 繁体字 (Traditional Chinese) (zh_TW) | BIG5 |
上に示されていない言語によるマニュアルページはサポートされません。
whatis データベースの内容をダンプして読みやすい形で出力します。 |
|
whatis データベースを検索して、指定した文字列を含むシステムコマンドの概略説明を表示します。 |
|
フォーマット済マニュアルページを生成、更新します。 |
|
指定されたマニュアルページについて、一行のサマリー情報を表示します。 |
|
指定されたマニュアルページを整形して表示します。 |
|
マニュアルページを別のエンコーディングに変換します。 |
|
whatis データベースを生成、更新します。 |
|
$MANPATH の内容を表示します。 あるいは ($MANPATH が設定されていない場合は) man.conf 内の設定とユーザー設定に基づいて適切な検索パスを表示します。 |
|
whatis データベースを検索して、指定されたキーワードを含むシステムコマンドの概略説明を表示します。 |
|
man に対しての実行時のサポート機能を提供します。 |
|
man に対しての実行時のサポート機能を提供します。 |
Procps-ng パッケージはプロセス監視を行うプログラムを提供します。
procps-ng をコンパイルするための準備をします。
./configure --prefix=/usr \ --docdir=/usr/share/doc/procps-ng-4.0.0 \ --disable-static \ --disable-kill \ --with-systemd
configure オプションの意味
--disable-kill
本スイッチは kill コマンドをビルドしないようにします。 このコマンドは Util-linux パッケージにてインストールされます。
パッケージをコンパイルします。
make
テストスイートを実行する場合は、以下を実行します。
make check
ホストディストリビューション上において、特定のアプリケーション(たとえば JVM や
ウェブブラウザー)が独自のメモリ割り当てを行っている場合に、free
with commit
という名前のテストが失敗します。
パッケージをインストールします。
make install
物理メモリ、スワップメモリの双方において、メモリの使用量、未使用量を表示します。 |
|
プロセスの名前などの属性によりプロセスを調べます。 |
|
指定されたプログラムの PID を表示します。 |
|
プロセスの名前などの属性によりプロセスに対してシグナルを送信します。 |
|
指定されたプロセスのメモリマップを表示します。 |
|
現在実行中のプロセスを一覧表示します。 |
|
実行前にプロセスの完了を待ちます。 |
|
プロセスが実行されているカレントディレクトリを表示します。 |
|
リアルタイムにカーネルのスラブキャッシュ(slab cache)情報を詳細に示します。 |
|
システム稼動中にカーネル設定を修正します。 |
|
システムの負荷平均 (load average) をグラフ化して表示します。 |
|
CPU をより多く利用しているプロセスの一覧を表示します。 これはリアルタイムにプロセッサーの動作状況を逐次表示します。 |
|
システムの稼動時間、ログインユーザー数、システム負荷平均 (load average) を表示します。 |
|
仮想メモリの統計情報を表示します。 そこではプロセス、メモリ、ページング、ブロック入出力 (Input/Output; IO)、トラップ、CPU 使用状況を表示します。 |
|
どのユーザーがログインしていて、どこから、そしていつからログインしているかを表示します。 |
|
指定されたコマンドを繰り返し実行します。 そしてその出力結果の先頭の一画面分を表示します。 出力結果が時間の経過とともにどのように変わるかを確認することができます。 |
|
本パッケージのほとんどのプログラムが利用している関数を提供します。 |
Util-linux パッケージはさまざまなユーティリティプログラムを提供します。 ファイルシステム、コンソール、パーティション、カーネルメッセージなどを取り扱うユーティリティです。
Util-linux をコンパイルするための準備をします。
./configure ADJTIME_PATH=/var/lib/hwclock/adjtime \ --bindir=/usr/bin \ --libdir=/usr/lib \ --sbindir=/usr/sbin \ --docdir=/usr/share/doc/util-linux-2.38.1 \ --disable-chfn-chsh \ --disable-login \ --disable-nologin \ --disable-su \ --disable-setpriv \ --disable-runuser \ --disable-pylibmount \ --disable-static \ --without-python
--disable と --without のオプションは、LFS では必要のないパッケージ、あるいは他のパッケージのインストールによって不整合となったパッケージに対して出力される警告をなくします。
パッケージをコンパイルします。
make
必要なら root
ユーザー以外にて、以下のようにテストスイートを実行します。
root
ユーザーによりテストスイートを実行すると、システムに悪影響を及ぼすことがあります。
テストスイートを実行するためには、カーネルオプション CONFIG_SCSI_DEBUG
が現環境にて有効であり、かつモジュールとしてビルドされていなければなりません。
カーネルに組み込んでいるとブートできません。 またテストを完全に実施するには BLFS
での各種パッケージのインストールも必要になります。 テストが必要であるなら、LFS
システムを完成した後に、再起動したシステムにて以下を実行します。
bash tests/run.sh --srcdir=$PWD --builddir=$PWD
chown -Rv tester . su tester -c "make -k check"
hardlinkテストは、カーネルオプションにおいて CONFIG_CRYPTO_USER_API_HASH セットが設定されていない場合は失敗します。
パッケージをインストールします。
make install
Linux カーネルに対して新しいパーティションの情報を通知します。 |
|
tty ポートを開いてログイン名の入力を受け付けます。 そして login プログラムを起動します。 |
|
デバイス上のセクターを取り除きます。 |
|
ブロックデバイスの属性を見つけて表示するためのコマンドラインユーティリティ。 |
|
指定されたブロックデバイスにおいてゾーンコマンドを実行します。 |
|
コマンドラインからブロックデバイスの ioctl の呼び出しを行います。 |
|
簡単なカレンダーを表示します。 |
|
指定されたデバイスのパーティションテーブルを操作します。 |
|
CPU の状態を変更します。 |
|
メモリを設定します。 |
|
OOM-killer スコアを表示し調整します。 |
|
リアルタイムプロセスの属性を操作します。 |
|
逆改行 (reverse line feeds) を取り除きます。 |
|
性能が不十分な端末のために nroff の出力結果から重ね書き (overstriking) や半改行 (half-lines) を取り除きます。 |
|
指定されたカラムを取り除きます。 |
|
指定されたファイルの内容を複数カラムに整形します。 |
|
ハードリセットまたはソフトリセットを行うために Ctrl+Alt+Del キー押下時の機能を設定します。 |
|
Linux カーネルに対してパーティションが削除されているかどうかを確認します。 |
|
カーネルのブートメッセージをダンプします。 |
|
リムーバブルメディアをイジェクトします。 |
|
ファイルのための領域を事前割り当てします。 |
|
指定されたデバイスのパーティションテーブルを操作します。 |
|
メモリコア内にあるファイル情報のページ数を調べます。 |
|
ファイルシステムに対するラベルまたは UUID (Universally Unique Identifier) を使ってファイルシステムを検索します。 |
|
libmount ライブラリに対するコマンドラインインターフェース。 mountinfo, fstab, mtab の各ファイルに対しての処理を行います。 |
|
ファイルロックを取得してロックしたままコマンドを実行します。 |
|
ファイルシステムのチェックを行い、必要に応じて修復を行います。 |
|
指定されたデバイス上の Cramfs ファイルシステムに対して一貫性検査 (consistency check) を行います。 |
|
指定されたデバイス上の Minix ファイルシステムに対して一貫性検査 (consistency check) を行います。 |
|
カーネルドライバー制御における FIFREEZE/FITHAW ioctl に対する単純なラッパープログラム。 |
|
マウントされたファイルシステム上にて、利用されていないブロックを破棄します。 |
|
指定されたコマンドラインのオプション引数を解析します。 |
|
指定されたファイルを 16進数書式または他の指定された書式でダンプします。 |
|
システムのハードウェアクロックを読み取ったり設定したりします。 このハードウェアクロックはリアルタイムクリック (Real-Time Clock; RTC) または BIOS (Basic Input-Output System) クロックとも呼ばれます。 |
|
setarch へのシンボリックリンク。 |
|
プログラムに対する I/O スケジュールクラスとスケジュール優先度を取得または設定します。 |
|
さまざまな IPC リソースを生成します。 |
|
指定された IPC (Inter-Process Communication) リソースを削除します。 |
|
IPC のステータス情報を提供します。 |
|
カーネルのインタラプトカウンター情報を |
|
iso9660 ファイルシステムのサイズを表示します。 |
|
プロセスに対してシグナルを送信します。 |
|
ユーザーの最新のログイン (ログアウト) の情報を表示します。 これは |
|
ログインに失敗した情報を表示します。 これは |
|
シリアル回線 (serial line) に対して回線規則 (line discipline) を割り当てます。 |
|
setarch へのシンボリックリンク。 |
|
setarch へのシンボリックリンク。 |
|
指定したメッセージをシステムログに出力します。 |
|
指定された文字列で始まる行を表示します。 |
|
ループデバイス (loop device) の設定と制御を行います。 |
|
ブロックデバイスのすべて、あるいは指定されたものの情報を、木構造のような形式で一覧表示します。 |
|
CPU アーキテクチャーの情報を表示します。 |
|
システムに搭載されている IPC 機能の情報を表示します。 |
|
カーネルのインタラプトカウンター情報を表示します。 |
|
ローカルのシステムロックを一覧表示します。 |
|
ユーザー、グループ、システムアカウントの情報を一覧表示します。 |
|
オンライン状態にある利用可能なメモリ範囲を一覧表示します。 |
|
名前空間を一覧表示します。 |
|
xauth のためのマジッククッキー (128ビットのランダムな16進数値) を生成します。 |
|
現在のユーザーの端末に対して、他のユーザーがメッセージ送信できるかどうかを制御します。 |
|
デバイス上にファイルシステムを構築します。 (通常はハードディスクパーティションに対して行います。) |
|
SCO (Santa Cruz Operations) の bfs ファイルシステムを生成します。 |
|
cramfs ファイルシステムを生成します。 |
|
Minix ファイルシステムを生成します。 |
|
指定されたデバイスまたはファイルをスワップ領域として初期化します。 |
|
テキストを一度に一画面分だけ表示するフィルタープログラム。 |
|
ファイルシステムツリー内の特定のディレクトリを、指定されたデバイス上のファイルシステムに割り当てます。 |
|
ディレクトリがマウントポイントであるかどうかをチェックします。 |
|
指定されたパスに存在するシンボリックリンクを表示します。 |
|
他プロセスの名前空間にてプログラムを実行します。 |
|
カーネルに対して、ディスク上にパーティションが存在するか、何番が存在するかを伝えます。 |
|
指定されたファイルシステムを、現在のプロセスに対する新しいルートファイルシステムにします。 |
|
プロセスが利用するリソースの限界値を取得または設定します。 |
|
カーネルのプロファイリング情報を読み込みます。 |
|
指定されたファイルの名称を変更します。 |
|
実行中のプロセスの優先度を変更します。 |
|
Linux カーネルに対してパーティションのリサイズを指示します。 |
|
指定されたファイル内の行の並びを入れ替えます。 |
|
ワイアレスデバイスの有効化、無効化を行うツール。 |
|
指定された起動時刻までの間、システムをスリープ状態とするモードを指定します。 |
|
端末セッション上での出力結果の写し (typescript) を生成します。 |
|
タイミング情報を使って、セッションのタイプスクリプトを再実行します。 |
|
タイミング情報 (timing information) を利用して、出力結果の写し (typescript) を再生します。 |
|
新しいプログラム環境にて、表示されるアーキテクチャーを変更します。 また設定フラグ (personality flag) の設定も行います。 |
|
新しいセッションで指定されたプログラムを実行します。 |
|
端末の属性を設定します。 |
|
ディスクパーティションテーブルを操作します。 |
|
|
|
スワップ領域の UUID とラベルを変更します。 |
|
ページングまたはスワッピングに利用しているデバイスまたはファイルを無効にします。 |
|
ページングまたはスワッピングに利用しているデバイスまたはファイルを有効にします。 また現在利用されているデバイスまたはファイルを一覧表示します。 |
|
別のファイルシステムを、マウントツリーのルートとして変更します。 |
|
プロセスの CPU 親和性 (affinity) を表示または設定します。 |
|
システムやプロセスの使用率クランプ属性を操作します。 |
|
使用中の端末にて、アンダースコア文字を、エスケープシーケンスを用いた下線文字に変換するためのフィルター。 |
|
システムのファイルツリーからファイルシステムを切断します。 |
|
setarch へのシンボリックリンク。 |
|
上位の名前空間とは異なる名前空間にてプログラムを実行します。 |
|
指定されたログインファイルの内容を分かりやすい書式で表示します。 |
|
UUID ライブラリから利用されるデーモン。 時刻情報に基づく UUID を、安全にそして一意性を確保して生成します。 |
|
新しい UUID を生成します。 生成される UUID は当然、他に生成されている UUID とは異なり、自他システムでも過去現在にわたってもユニークなものです。 |
|
ユニークな識別子を解析するためのユーティリティー。 |
|
ファイルの内容、あるいはデフォルトでは標準入力から入力された内容を、現在ログインしている全ユーザーの端末上に表示します。 |
|
ハードウェアの watchdog ステータスを表示します。 |
|
指定されたコマンドの実行モジュール、ソース、man ページの場所を表示します。 |
|
ファイルシステムのシグニチャーをデバイスから消去します。 |
|
setarch へのシンボリックリンク。 |
|
zram (compressed ram disk) デバイスを初期化し制御するためのプログラム。 |
|
デバイスの識別やトークンの抽出を行う処理ルーチンを提供します。 |
|
パーティションテーブルを操作する処理ルーチンを提供します。 |
|
ブロックデバイスのマウントとアンマウントに関する処理ルーチンを提供します。 |
|
タブラー形式 (tabular form) による画面出力を補助する処理ルーチンを提供します。 |
|
ローカルシステム内だけに限らずアクセスされるオブジェクトに対して、一意性が保証された識別子を生成する処理ルーチンを提供します。 |
e2fsprogs パッケージは ext2
ファイルシステムを扱うユーティリティを提供します。これは同時に ext3
、ext4
ジャーナリングファイルシステムもサポートします。
e2fsprogs パッケージは、ソースディレクトリ内にサブディレクトリを作ってビルドすることが推奨されています。
mkdir -v build cd build
e2fsprogs をコンパイルするための準備をします。
../configure --prefix=/usr \ --sysconfdir=/etc \ --enable-elf-shlibs \ --disable-libblkid \ --disable-libuuid \ --disable-uuidd \ --disable-fsck
configure オプションの意味
--enable-elf-shlibs
このオプションは、本パッケージ内のプログラムが利用する共有ライブラリを生成します。
--disable-*
このオプションは libuuid
ライブラリ、libblkid
ライブラリ、uuidd
デーモン、fsck
ラッパーをいずれもビルドせずインストールしないようにします。 これらは util-linux
パッケージによって、より最新のものがインストールされています。
パッケージをコンパイルします。
make
コンパイル結果をテストするには以下を実行します。
make check
u_direct_io という 1 つのテストが、システムによっては失敗する場合があります。
パッケージをインストールします。
make install
不要なスタティックライブラリを削除します。
rm -fv /usr/lib/{libcom_err,libe2p,libext2fs,libss}.a
本パッケージは gzip 圧縮された.info
ファイルをインストールしますが、共通的な dir
を更新しません。 そこで以下のコマンドにより gzip ファイルを解凍した上で dir
ファイルを更新します。
gunzip -v /usr/share/info/libext2fs.info.gz install-info --dir-file=/usr/share/info/dir /usr/share/info/libext2fs.info
必要なら、以下のコマンドを実行して追加のドキュメントをインストールします。
makeinfo -o doc/com_err.info ../lib/et/com_err.texinfo install -v -m644 doc/com_err.info /usr/share/info install-info --dir-file=/usr/share/info/dir /usr/share/info/com_err.info
デバイス (通常はディスクパーティション) の不良ブロックを検索します。 |
|
|
|
エラーテーブルコンパイラー。 これはエラーコード名とメッセージの一覧を、 |
|
ファイルシステムデバッガー。 これは |
|
指定されたデバイス上にあるファイルシステムについて、スーパーブロックの情報とブロックグループの情報を表示します。 |
|
フリースペースのフラグメント情報を表示します。 |
|
|
|
|
|
指定されたデバイス上にある |
|
ext4 ファイルシステムの MMP ステータスをチェックします。 |
|
マウントされている ext[234] ファイルシステムの内容をチェックします。 |
|
マウントされている ext[234] ファイルシステムのエラーをチェックします。 |
|
デバイス上にある ext2/ext3/ext4 ファイルシステムの undo ログを再実行します。 これは e2fsprogs プログラムが処理に失敗した際に undo を行うこともできます。 |
|
ext4 ファイルシステムの暗号化ユーティリティー。 |
|
ext4 ファイルシステムにたいするオンラインのデフラグプログラム。 |
|
特定のファイルがどのようにデフラグ化しているかを表示します。 |
|
デフォルトでは |
|
デフォルトでは |
|
デフォルトでは |
|
コマンドの出力結果をログファイルに保存します。 |
|
|
|
コマンド名とヘルプメッセージの一覧を、サブシステムライブラリ |
|
指定されたデバイス上に |
|
デフォルトでは |
|
デフォルトでは |
|
デフォルトでは |
|
|
|
|
|
|
|
共通的なエラー表示ルーチン。 |
|
dumpe2fs、chattr、lsattr の各コマンドが利用します。 |
|
ユーザーレベルのプログラムが |
|
debugfs コマンドが利用します。 |
プログラムやライブラリの多くは、デフォルトではデバッグシンボルを含めてコンパイルされています。 (gcc の -g
オプションが用いられています。)
デバッグ情報を含めてコンパイルされたプログラムやライブラリは、デバッグ時にメモリアドレスが参照できるだけでなく、処理ルーチンや変数の名称も知ることができます。
しかしそういったデバッグ情報は、プログラムやライブラリのファイルサイズを極端に大きくします。 以下にデバッグシンボルが占める割合の例を示します。
デバッグシンボルを含んだ bash の実行ファイル: 1200 KB
デバッグシンボルを含まない bash の実行ファイル: 480 KB
デバッグシンボルを含んだ Glibc と GCC の関連ファイル (/lib
と /usr/lib
): 87 MB
デバッグシンボルを含まない Glibc と GCC の関連ファイル: 16MB
利用するコンパイラーや C ライブラリの違いによって、生成されるファイルのサイズは異なります。 デバッグシンボルを含む、あるいは含まないサイズを比較した場合、その差は 2倍から 5倍の違いがあります。
プログラムをデバッグするユーザーはそう多くはありません。 デバッグシンボルを削除すればディスク容量はかなり節減できます。 次節ではプログラムやライブラリからデバッグシンボルを取り除く (strip する) 方法を示します。
本節での作業を行うかどうかは任意です。 対象ユーザーがプログラマーではなく、プログラム類をデバッグするような使い方をしないのであれば、実行ファイルやライブラリに含まれるデバッグシンボルや不要シンボルを削除しても構いません。 そうすれば 2 GB ものサイズ削減を図ることができます。 たとえデバッグできなくなっても困らないはずです。
以下に示すコマンドは簡単なものです。 ただし入力つづりは簡単に間違いやすいので、もし誤った入力をするとシステムを利用不能にしてしまいます。 したがって strip コマンドを実行する前に、現時点の LFS システムのバックアップを取っておくことをお勧めします。
strip コマンドに
--strip-unneeded
オプションをつけて実行すると、バイナリやライブラリからデバッグシンボルをすべて削除します。
そして(スタティックライブラリ向けの)リンカーや(動的リンクバイナリあるいは共有ライブラリ向けの)ダイナミックリンカーにとって不要なシンボルテーブル項目もすべて削除します。
ライブラリのいくつかについて、デバッグシンボルを持つような別ファイルを生成します。 このデバッグ情報を必要とするのは BLFS における valgrind または gdb の縮退テストを実施するのに必要であるからです。
なお strip
は、処理しているバイナリファイルやライブラリファイルを上書きします。
そのファイルにあるコードやデータを利用しているプロセスは、これによってクラッシュすることがあります。 仮に
strip
自体を実行しているプロセスがその影響を受けたとすると、ストリップ最中のバイナリやライブラリは壊れてしまうかもしれません。
これが起きると、システムが完全に利用不能となりかねません。 これを避けるため、ライブラリやバイナリのいくつかを
/tmp
にコピーして、そこでストリップした上で、install
コマンドを使って、元の場所にインストールし直すことにします。 ここで install
コマンドを利用する意味については、「アップグレードに関する問題」
に示す関連項目を参照してください。
ELF ローダーの名前は、64 ビットシステムでは ld-linux-x86-64.so.2、32 ビットシステムでは ld-linux.so.2 です。 後述の手順では、現行のアーキテクチャーに合わせて適切な名前を選ぶようにしています。 ただし「g」で終わるものは除いています。 そのようなものはすでにコマンド実行されているからです。
save_usrlib="$(cd /usr/lib; ls ld-linux*[^g]) libc.so.6 libthread_db.so.1 libquadmath.so.0.0.0 libstdc++.so.6.0.30 libitm.so.1.0.0 libatomic.so.1.2.0" cd /usr/lib for LIB in $save_usrlib; do objcopy --only-keep-debug $LIB $LIB.dbg cp $LIB /tmp/$LIB strip --strip-unneeded /tmp/$LIB objcopy --add-gnu-debuglink=$LIB.dbg /tmp/$LIB install -vm755 /tmp/$LIB /usr/lib rm /tmp/$LIB done online_usrbin="bash find strip" online_usrlib="libbfd-2.39.so libhistory.so.8.1 libncursesw.so.6.3 libm.so.6 libreadline.so.8.1 libz.so.1.2.12 $(cd /usr/lib; find libnss*.so* -type f)" for BIN in $online_usrbin; do cp /usr/bin/$BIN /tmp/$BIN strip --strip-unneeded /tmp/$BIN install -vm755 /tmp/$BIN /usr/bin rm /tmp/$BIN done for LIB in $online_usrlib; do cp /usr/lib/$LIB /tmp/$LIB strip --strip-unneeded /tmp/$LIB install -vm755 /tmp/$LIB /usr/lib rm /tmp/$LIB done for i in $(find /usr/lib -type f -name \*.so* ! -name \*dbg) \ $(find /usr/lib -type f -name \*.a) \ $(find /usr/{bin,sbin,libexec} -type f); do case "$online_usrbin $online_usrlib $save_usrlib" in *$(basename $i)* ) ;; * ) strip --strip-unneeded $i ;; esac done unset BIN LIB save_usrlib online_usrbin online_usrlib
ファイルフォーマットが認識できないファイルがいくつも警告表示されますが、無視して構いません。 この警告は、処理したファイルが実行モジュールではなくスクリプトファイルであることを示しています。
テストを通じて生成された不要なファイル等を削除します。
rm -rf /tmp/*
また /usr/lib ディレクトリと /usr/libexec ディレクトリには、拡張子が .la であるファイルがいくつかインストールされます。 これは "libtool アーカイブ" ファイルというものであり、すでに説明しているように、これはスタティックライブラリとリンクする際に利用します。 これらはダイナミック共有ライブラリを用いるとき、そして特に autotools 以外のビルドシステムを利用するときには不要であり、潜在的には支障を及ぼします。 削除する場合は以下を実行します。
find /usr/lib /usr/libexec -name \*.la -delete
libtool アーカイブファイルについての詳細は BLFS の節 "About Libtool Archive (.la) files" を参照してください。
第 6 章 と 第 7 章 においてビルドしたコンパイラーは、部分的にしかインストールしていませんが、これ以降は必要としません。 そこで以下によって削除します。
find /usr -depth -name $(uname -m)-lfs-linux-gnu\* | xargs rm -rf
最後に、本章のはじめに生成した 'tester' ユーザーアカウントを削除します。
userdel -r tester
本章ではシステム設定ファイルと systemd サービスについて説明します。 まずはネットワークの設定に必要となる一般的な設定ファイルです。
次にデバイスを適切に設定するための方法について説明します。
そしてシステムクロックとキーボードレイアウトです。
またユーザーログの出力に利用されるスクリプトや設定ファイルについて触れます。
最後に systemd の処理設定です。
本節はネットワークカードを設定する場合にのみ作業を行っていきます。
systemd はバージョン 209 から、ネットワーク設定を行うデーモン systemd-networkd
を提供するようになりました。 このデーモンが基本的なネットワーク設定を行います。 さらにバージョン 213 からは、DNS
名前解決を固定的に /etc/resolv.conf
ファイルによって行っていたものが systemd-resolved
により行うよう変更されています。 いずれのデーモンもデフォルトで有効となっています。
If you will not use systemd-networkd for network configuration (for example, when the system is not connected to network, or you want to use another utility like NetworkManager for network configuration), disable a service to prevent an error message during boot:
systemctl disable systemd-networkd-wait-online
systemd-networkd (および
systemd-resolved)
に対する設定ファイルは /usr/lib/systemd/network
ディレクトリまたは
/etc/systemd/network
ディレクトリに置きます。 /usr/lib/systemd/network
ディレクトリにある設定ファイルよりも
/etc/systemd/network
ディレクトリにある設定ファイルの方が優先されます。 設定ファイルには .link
, .netdev
, .network
の三種類があります。 これらの説明や設定例については man ページ
systemd-link(5)
, systemd-netdev(5)
, systemd-network(5)
を参照してください。
通常 Udev は、システムの物理的な特性に従った enp2s1 などのような名称をネットワークカードインターフェースに割り当てます。 インタフェース名が分からない場合は、システム起動直後に ip link を実行して確認してください。
インターフェース名は、システム上で起動している udev デーモンの実装や設定に依存します。 LFS における udev デーモン(「Systemd-251」においてインストール)は、LFS システムを起動させるまでは動作しません。 したがってホストディストリビューションにおいて各コマンドを実行しても、LFS 上において用いられるインターフェース名が何であるのかは特定できません。 それは chroot 環境内においても同じことです。
システムにおいて、接続タイプに応じたネットワークインターフェースは、それぞれに 1 つであるのが通常です。 例えば有線接続のインターフェース名は、従来より eth0 とされます。 また無線接続の場合は wifi0 や wlan0 といった名前が用いられます。
ネットワークインターフェース名を従来どおりとしたり、カスタマイズしたりするには、以下に示す 3 通りの方法があります。
udev のデフォルトポリシーに対する .link ファイルをマスクして無効にします。
ln -s /dev/null /etc/systemd/network/99-default.link
インターフェースに対する名前として "internet0", "dmz0", "lan0" といった命名スキームを自分で定めます。 これを行うには /etc/systemd/network/ ディレクトリに .link ファイルを生成し、必要なインターフェースに対して具体的な名前、つまりより良い命名スキームを定めます。 例えば以下のようにします。
cat > /etc/systemd/network/10-ether0.link << "EOF"
[Match]
# Change the MAC address as appropriate for your network device
MACAddress=12:34:45:78:90:AB
[Link]
Name=ether0
EOF
詳細は man ページ systemd.link(5) を確認してください。
/boot/grub/grub.cfg ファイル内において、カーネルの設定行に net.ifnames=0 を追加します。
以下のコマンドは固定IPアドレスの設定を行う設定ファイルを生成するものです。 (systemd-networkd と systemd-resolved を利用します。)
cat > /etc/systemd/network/10-eth-static.network << "EOF"
[Match]
Name=<network-device-name>
[Network]
Address=192.168.0.2/24
Gateway=192.168.0.1
DNS=192.168.0.1
Domains=<Your Domain Name>
EOF
複数のDNSサーバーを有している場合は、DNS設定行を複数指定することができます。 固定的に /etc/resolv.conf
ファイルを利用する場合は DNS および
Domains の設定行は記載しません。
インターネットへの接続を行う場合には、ドメイン名サービス (domain name service; DNS)
による名前解決を必要とします。 これによりインターネットドメイン名を IP アドレスに、あるいはその逆の変換を行います。
これを行うには ISP やネットワーク管理者が指定する DNS サーバーの割り振り IP アドレスを
/etc/resolv.conf
ファイルに設定します。
ネットワークインターフェース設定を systemd-resolved とは別の方法 (例えば ppp など)
で行う場合、 または別のタイプのローカルリゾルバー (local resolver; たとえば bind や
dnsmasq や unbound など) や /etc/resolv.conf
を生成するソフトウェア (つまり
systemd が提供するものでない resolvconf プログラム)
などを用いる場合、systemd-resolved
サービスは用いてはなりません。
systemd-resolved を無効にするには、以下のコマンドを実行します。
systemctl disable systemd-resolved
DNS 設定に systemd-resolved を用いると
/run/systemd/resolve/resolv.conf
ファイルが生成されます。 また /etc/resolv.conf
が存在していない場合は、systemd-resolved が
/run/systemd/resolve/stub-resolv.conf
へのシンボリックリンクとして生成します。 その場合は /etc/resolv.conf
を手動で生成する必要はありません。
スタティックな /etc/resolv.conf
ファイルを必要とする場合は、以下のコマンドにより生成します。
cat > /etc/resolv.conf << "EOF"
# Begin /etc/resolv.conf
domain <Your Domain Name>
nameserver <IP address of your primary nameserver>
nameserver <IP address of your secondary nameserver>
# End /etc/resolv.conf
EOF
domain
ステートメントは省略するか、search
ステートメントで代用することが可能です。 詳しくは resolv.conf の man ページを参照してください。
<IP address of the
nameserver>
(ネームサーバーの IP アドレス) の部分には、DNS
が割り振る適切な IP アドレスを記述します。 IP
アドレスの設定は複数行う場合もあります。(代替構成を必要とするなら二次サーバーを設けることでしょう。)
一つのサーバーのみで十分な場合は、二つめの nameserver の行は削除します。
ローカルネットワークにおいてはルーターの IP アドレスを設定することになるでしょう。 これ以外の方法として、IP
アドレスに Google Public DNS サービスをネームサーバーとして利用する方法もあります。
Google Public IPv4 DNS アドレスは 8.8.8.8
と 8.8.4.4
です。 また IPv6 では
2001:4860:4860::8888
と
2001:4860:4860::8844
です。
システム起動時には /etc/hostname
が参照されてシステムのホスト名が決定されます。
以下のコマンドを実行することで /etc/hostname
ファイルを生成するとともに、ホスト名を設定します。
echo "<lfs>
" > /etc/hostname
<lfs>
の部分は、各システムにおいて定めたい名称に置き換えてください。 ここでは完全修飾ドメイン名 (Fully
Qualified Domain Name; FQDN) は指定しないでください。 その情報は /etc/hosts
ファイルにて行います。
完全修飾ドメイン名 (Fully Qualified Domain Name; FQDN)、エイリアスの各設定は
/etc/hosts
ファイルにて行います。
固定アドレスを用いる場合は IPアドレスを定める必要があります。 ホストファイルの文法は以下のとおりです。
IP_address myhost.example.org aliases
インターネットに公開されていないコンピューターである場合 (つまり登録ドメインであったり、あらかじめ IP アドレスが割り当てられていたりする場合。 普通のユーザーはこれを持ちません。) IP アドレスはプライベートネットワーク IP アドレスの範囲で指定します。 以下がそのアドレス範囲です。
Private Network Address Range Normal Prefix
10.0.0.1 - 10.255.255.254 8
172.x.0.1 - 172.x.255.254 16
192.168.y.1 - 192.168.y.254 24
x は 16 から 31、y は 0 から 255 の範囲の数値です。
IP アドレスの例は 192.168.1.1 となります。 また FQDN の例としては lfs.example.org となります。
ネットワークカードを用いない場合でも FQDN の記述は行ってください。 MTA のような特定のプログラムが動作する際に必要となることがあるからです。
以下のようにして /etc/hosts
ファイルを生成します。
cat > /etc/hosts << "EOF"
# Begin /etc/hosts
127.0.0.1 localhost.localdomain localhost
127.0.1.1 <FQDN>
<HOSTNAME>
<192.168.0.2>
<FQDN>
<HOSTNAME>
[alias1] [alias2] ...
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
# End /etc/hosts
EOF
<192.168.0.2>
,
<FQDN>
,
<HOSTNAME>
の部分は利用状況に応じて書き換えてください。 (ネットワーク管理者から IP
アドレスを指定されている場合や、既存のネットワーク環境に接続する場合など。). エイリアスの記述は省略しても構いません。
また <192.168.0.2>
の行も、DHCP
や IPv6 による自動設定による接続を行う場合には省略可能です。
::1 という項目は IPv6 における 127.0.0.1 に相当し、IPv6 のループバックインターフェースを表します。 127.0.1.1 は FQDN に対して特別に割り当てられたループバック項目です。
第 8 章の systemd のビルドを通じて Udev パッケージをインストールしました。 このパッケージがどのように動作するかの詳細を説明する前に、デバイスを取り扱うかつての方法について順を追って説明していきます。
Linux システムは一般に、スタティックなデバイス生成方法を採用していました。 この方法では /dev
のもとに膨大な量の (場合によっては何千にもおよぶ)
デバイスノードが生成されます。 実際にハードウェアデバイスが存在するかどうかに関わらずです。 これは MAKEDEV スクリプトを通じて生成されます。
このスクリプトからは mknod
プログラムが呼び出されますが、その呼び出しは、この世に存在するありとあらゆるデバイスのメジャー/マイナー番号を用いて行われます。
udev による方法では、カーネルが検知したデバイスだけがデバイスノードとなります。
デバイスノードはシステムが起動するたびに生成されることになるので、 devtmpfs
ファイルシステム上に保存されます。 (devtmpfs
は仮想ファイルシステムであり、メモリ上に置かれます。)
デバイスノードの情報はさほど多くないので、消費するメモリ容量は無視できるほど少ないものです。
2000年2月に新しいファイルシステム devfs
がカーネル 2.3.46 に導入され、2.4系の安定版カーネルにて利用できるようになりました。
このファイルシステムはカーネルのソース内に含まれ実現されていましたが、デバイスを動的に生成するこの手法は、主要なカーネル開発者の十分な支援は得られませんでした。
devfs
が採用した手法で問題になるのは、主にデバイスの検出、生成、命名の方法です。
特にデバイスの命名方法がおそらく最も重大な問題です。
一般的に言えることとして、デバイス名が変更可能であるならデバイス命名の規則はシステム管理者が考えることであって、特定の開発者に委ねるべきことではありません。
また devfs
にはその設計に起因した競合の問題があるため、根本的にカーネルを修正しなければ解消できる問題ではありません。
そこで長い間、保守されることがなかったために非推奨 (deprecated) として位置づけられ、最終的に
2006年6月にはカーネルから取り除かれました。
開発版の 2.5 系カーネルと、後にリリースされた安定版のカーネル 2.6 系を経て、新しい仮想ファイルシステム
sysfs
が登場しました。 sysfs
が実現したのは、システムのハードウェア設定をユーザー空間のプロセスとして表に出したことです。
ユーザー空間での設定を可視化したことによって devfs
が為していたことを、ユーザー空間にて開発することが可能になったわけです。
sysfs
ファイルシステムについては上で簡単に触れました。 sysfs
はどのようにしてシステム上に存在するデバイスを知るのか、そしてどのデバイス番号を用いるべきなのか。
そこが知りたいところです。
カーネルに直接組み込まれて構築されたドライバーの場合は、対象のオブジェクトをカーネルが検出し、そのオブジェクトを
sysfs
(内部的には devtmpfs)
に登録します。 モジュールとしてコンパイルされたドライバーの場合は、その登録がモジュールのロード時に行われます。
sysfs
ファイルシステムが (/sys に)
マウントされると、ドライバーによって sysfs
に登録されたデータは、ユーザー空間のプロセスと (デバイスノードの修正を含む) さまざまな処理を行う udevd
にて利用可能となります。
デバイスファイルはカーネルによって、devtmpfs
ファイルシステム上に作り出されます。 デバイスノードを登録しようとするドライバーは (デバイスコア経由で)
devtmpfs
を通じて登録を行います。
devtmpfs
のインスタンスが
/dev
上にマウントされると、デバイスノードには固定的な名称、パーミッション、所有者の情報が設定され生成されます。
この後にカーネルは udevd に対して uevent を送信します。
udevd
は、/etc/udev/rules.d
,
/usr/lib/udev/rules.d
,
/run/udev/rules.d
の各ディレクトリ内にあるファイルの設定ルールに従って、デバイスノードに対するシンボリックリンクを生成したり、パーミッション、所有者、グループの情報を変更したり、内部的な
udevd
データベースの項目を修正したりします。
上の三つのディレクトリ内にて指定されるルールは番号づけされており、三つのディレクトリの内容は一つにまとめられます。
デバイスノードの生成時に udevd
がそのルールを見つけ出せなかった時は、devtmpfs
が利用される際の初期のパーミッションと所有者の情報のままとなります。
モジュールとしてコンパイルされたデバイスドライバーの場合、デバイス名の別名が作り出されています。 その別名は
modinfo
プログラムを使えば確認することができます。
そしてこの別名は、モジュールがサポートするバス固有の識別子に関連づけられます。 例えば snd-fm801 ドライバーは、ベンダーID 0x1319
とデバイスID 0x0801 の PCI ドライバーをサポートします。 そして「pci:v00001319d00000801sv*sd*bc04sc01i*」というエイリアスがあります。
たいていのデバイスでは、sysfs
を通じてドライバーがデバイスを扱うものであり、ドライバーのエイリアスをバスドライバーが提供します。
/sys/bus/pci/devices/0000:00:0d.0/modalias
ファイルならば「pci:v00001319d00000801sv00001319sd00001319bc04sc01i00」という文字列を含んでいるはずです。
udev が提供するデフォルトの生成規則によって udevd から /sbin/modprobe
が呼び出されることになり、その際には uevent に関する環境変数 MODALIAS
の設定内容が利用されます。 (この環境変数の内容は sysfs 内の
modalias
ファイルの内容と同じはずです。)
そしてワイルドカードが指定されているならそれが展開された上で、エイリアス文字列に合致するモジュールがすべてロードされることになります。
上の例で forte ドライバーがあったとすると、snd-fm801 の他にそれもロードされてしまいます。 これは古いものでありロードされて欲しくないものです。 不要なドライバーのロードを防ぐ方法については後述しているので参照してください。
カーネルは、ネットワークプロトコル、ファイルシステム、NLS サポートといった各種モジュールも、要求に応じてロードすることもできます。
自動的にデバイスが生成される際には、いくつか問題が発生します。
udev がモジュールをロードできるためには、バス固有のエイリアスがあって、バスドライバーが sysfs
に対して適切なエイリアスを提供していることが必要です。
そうでない場合は、別の手段を通じてモジュールのロードを仕組まなければなりません。 Linux-5.19.2 においての
udev は、INPUT、IDE、PCI、USB、SCSI、SERIO、FireWire
の各デバイスに対するドライバーをロードします。 それらのデバイスドライバーが適切に構築されているからです。
目的のデバイスドライバーが udev に対応しているかどうかは、modinfo
コマンドに引数としてモジュール名を与えて実行します。 /sys/bus
ディレクトリ配下にあるそのデバイス用のディレクトリを見つけ出して、modalias
ファイルが存在しているかどうかを見ることで分かります。
sysfs
に modalias
ファイルが存在しているなら、そのドライバーはデバイスをサポートし、デバイスとの直接のやり取りが可能であることを表します。
ただしエイリアスを持っていなければ、それはドライバーのバグです。 その場合は udev
に頼ることなくドライバーをロードするしかありません。 そしてそのバグが解消されるのを待つしかありません。
/sys/bus
ディレクトリ配下の対応するディレクトリ内に modalias
ファイルがなかったら、これはカーネル開発者がそのバス形式に対する
modalias のサポートをまだ行っていないことを意味します。 Linux-5.19.2 では ISA
バスがこれに該当します。 最新のカーネルにて解消されることを願うしかありません。
Udev は snd-pcm-oss のような「ラッパー (wrapper)」ドライバーや loop のような、現実のハードウェアに対するものではないドライバーは、ロードすることができません。
「ラッパー
(wrapper)」モジュールが単に他のモジュールの機能を拡張するだけのものであるなら
(例えば snd-pcm-oss は
snd-pcm
の機能拡張を行うもので、OSS アプリケーションに対してサウンドカードを利用可能なものにするだけのものであるため)
modprobe
の設定によってラッパーモジュールを先にロードし、その後でラップされるモジュールがロードされるようにします。
これは以下のように、対応する /etc/modprobe.d/
ファイル内にて「softdep」の記述行を加えることで実現します。
<filename>
.conf
softdep snd-pcm post: snd-pcm-oss
「softdep」コマンドは pre:
を付与することもでき、あるいは pre:
と post:
の双方を付与することもできます。 その記述方法や機能に関する詳細は man ページ modprobe.d(5)
を参照してください。
問題のモジュールがラッパーモジュールではなく、単独で利用できるものであれば、 modules
ブートスクリプトを編集して、システム起動時にこのモジュールがロードされるようにします。 これは
/etc/sysconfig/modules
ファイルにて、そのモジュール名を単独の行に記述することで実現します。
この方法はラッパーモジュールに対しても動作しますが、この場合は次善策となります。
不必要なモジュールはこれをビルドしないことにするか、あるいは /etc/modprobe.d/blacklist.conf
ファイルにブラックリスト (blacklist) として登録してください。 例えば forte
モジュールをブラックリストに登録するには以下のようにします。
blacklist forte
ブラックリストに登録されたモジュールは modprobe コマンドを使えば手動でロードすることもできます。
デバイス生成規則が意図したデバイスに合致していないと、この状況が往々にして起こります。 例えば生成規則の記述が不十分であった場合、SCSI ディスク (本来望んでいるデバイス) と、それに対応づいたものとしてベンダーが提供する SCSI ジェネリックデバイス (これは誤ったデバイス) の両方に生成規則が合致してしまいます。 記述されている生成規則を探し出して正確に記述してください。 その際には udevadm info コマンドを使って情報を確認してください。
この問題は、一つ前に示したものが別の症状となって現れたものかもしれません。 そのような理由でなく、生成規則が正しく
sysfs
の属性を利用しているのであれば、それはカーネルの処理タイミングに関わる問題であって、カーネルを修正すべきものです。
今の時点では、該当する sysfs
の属性の利用を待ち受けるような生成規則を生成し、/etc/udev/rules.d/10-wait_for_sysfs.rules
ファイルにそれを追加することで対処できます。 (/etc/udev/rules.d/10-wait_for_sysfs.rules
ファイルがなければ新規に生成します。) もしこれを実施してうまくいった場合は LFS
開発メーリングリストにお知らせください。
ここでは以下のことを前提としています。 まずドライバーがカーネル内に静的に組み入れられて構築されているか、あるいは既にモジュールとしてロードされていること。 そして udev が異なった名前のデバイスを生成していないことです。
Udev がデバイスノード生成のために必要となる情報を知るためには、カーネルドライバーが sysfs
に対して属性データを提供していなければなりません。
これはカーネルツリーの外に配置されるサードパーティ製のドライバーであれば当たり前のことです。 したがって
/usr/lib/udev/devices
において、適切なメジャー、マイナー番号を用いた静的なデバイスノードを生成してください。 (カーネルのドキュメント
devices.txt
またはサードパーティベンダーが提供するドキュメントを参照してください。)
この静的デバイスノードは、udev によって /dev
にコピーされます。
これは udev の設計仕様に従って発生するもので、uevent の扱いとモジュールのロードが平行して行われるためです。 このために命名順が予期できないものになります。 これを「固定的に」することはできません。 ですからカーネルがデバイス名を固定的に定めるようなことを求めるのではなく、シンボリックリンクを用いた独自の生成規則を作り出して、そのデバイスの固定的な属性を用いた固定的な名前を用いる方法を取ります。 固定的な属性とは例えば、udev によってインストールされるさまざまな *_id という名のユーティリティが出力するシリアル番号などです。 設定例については 「デバイスの管理」や 「全般的なネットワークの設定」を参照してください。
さらに参考になるドキュメントが以下のサイトにあります:
「デバイスとモジュールの扱いについて」で説明したように、/dev
内に同一機能を有するデバイスがあったとすると、その検出順は本質的にランダムです。 例えば USB 接続のウェブカメラと
TV チューナーがあったとして、/dev/video0
がウェブカメラを、また /dev/video1
がチューナーをそれぞれ参照していたとしても、システム起動後はその順が変わることがあります。
サウンドカードやネットワークカードを除いた他のハードウェアであれば、udev
ルールを適切に記述することで、固定的なシンボリックリンクを作り出すことができます。 ネットワークカードについては、別途
「全般的なネットワークの設定」にて説明しています。
またサウンドカードの設定方法は
BLFS にて説明しています。
利用しているデバイスに上の問題の可能性がある場合 (お使いの Linux
ディストリビューションではそのような問題がなかったとしても) /sys/class
ディレクトリや /sys/block
ディレクトリ配下にある対応ディレクトリを探してください。
ビデオデバイスであれば /sys/class/video4linux/video
といったディレクトリです。
そしてそのデバイスを一意に特定する識別情報を確認してください。
(通常はベンダー名、プロダクトID、シリアル番号などです。)
X
udevadm info -a -p /sys/class/video4linux/video0
シンボリックリンクを生成するルールを作ります。
cat > /etc/udev/rules.d/83-duplicate_devs.rules << "EOF"
# Persistent symlinks for webcam and tuner
KERNEL=="video*", ATTRS{idProduct}=="1910", ATTRS{idVendor}=="0d81", SYMLINK+="webcam"
KERNEL=="video*", ATTRS{device}=="0x036f", ATTRS{vendor}=="0x109e", SYMLINK+="tvtuner"
EOF
こうしたとしても /dev/video0
と
/dev/video1
はチューナーとウェブカメラのいずれかをランダムに指し示すことに変わりありません。
(したがって直接このデバイス名を使ってはなりません。) しかしシンボリックリンク /dev/tvtuner
と /dev/webcam
は常に正しいデバイスを指し示すようになります。
本節ではシステムサービス systemd-timedated の設定方法について示します。 このサービスはシステムクロックとタイムゾーンの設定を行うものです。
ハードウェアクロックが UTC に設定されているかどうか忘れた場合は hwclock --localtime --show
を実行すれば確認できます。 このコマンドにより、ハードウェアクロックに基づいた現在時刻が表示されます。
その時刻が手元の時計と同じ時刻であれば、ローカル時刻として設定されているわけです。
一方それがローカル時刻でなかった場合は、おそらくは UTC に設定されているからでしょう。 hwclock
によって示された時刻からタイムゾーンに応じた一定時間を加減してみてください。 例えばタイムゾーンが MST
であった場合、これは GMT -0700 なので、7時間を加えればローカル時刻となります。
systemd-timedated
コマンドは /etc/adjtime
ファイルを読み込みます。
そしてこのファイルの設定内容に応じて、システムクロックを UTC かあるいはローカル時刻に設定します。
ハードウェアクロックをローカル時刻に設定する場合は、以下の内容により /etc/adjtime
ファイルを生成します。
cat > /etc/adjtime << "EOF"
0.0 0 0.0
0
LOCAL
EOF
起動時に /etc/adjtime
ファイルが存在しなかった場合、ハードウェアクロックは UTC に設定されているものとして systemd-timedated
が判断し、このファイルを調整します。
timedatectl ユーティリティーを用いる方法もあります。 これを使って systemd-timedated に対し、ハードウェアクロックが UTC かローカル時刻かを設定することができます。
timedatectl set-local-rtc 1
timedatectl コマンドを用いれば、システム時刻やタイムゾーンを変更することもできます。
システム時刻を変更するには以下を実行します。
timedatectl set-time YYYY-MM-DD HH:MM:SS
ハードウェアクロックも同様に設定することができます。
タイムゾーンを変更するには以下を実行します。
timedatectl set-timezone TIMEZONE
利用可能なタイムゾーンの一覧は以下を実行して確認できます。
timedatectl list-timezones
timedatectl コマンドは chroot 環境内では動作しない点に注意してください。 systemd を使って LFS システムを起動したときになって、初めて利用できるものです。
systemd のバージョン 213 からは systemd-timesyncd というデーモンが提供されています。 これはシステム時刻とリモートの NTP サーバーの時刻同期を行うものです。
このデーモンは、NTP デーモンとして充実したものではありません。 NTP デーモンに代わるものと位置づけられるものではなく、SNTP プロトコルのクライアントのみの実装であり、簡単なタスクの処理やリソースが限られているシステム上にて用いられます。
systemd のバージョン 216 からはデフォルトで systemd-timesyncd デーモンが用いられます。 これを無効にしたい場合は以下を実行します。
systemctl disable systemd-timesyncd
systemd-timesyncd が利用する NTP
サーバーを変更するには /etc/systemd/timesyncd.conf
ファイルを用います。
システムクロックがローカル時刻に設定されている場合、systemd-timesyncd はハードウェアクロックを更新しない点に注意してください。
この節ではシステムサービス systemd-vconsole-setup の設定方法について説明します。 このサービスは仮想コンソールフォントとコンソールキーマップを設定します。
systemd-vconsole-setup
サービスは、/etc/vconsole.conf
ファイルにて示される設定情報を読み込みます。 キーマップやスクリーンフォントには何を用いるのかを定めてください。
各言語に対する HOWTO も確認してください。 http://www.tldp.org/HOWTO/HOWTO-INDEX/other-lang.html
が参考になるでしょう。 localectl
list-keymaps を実行すると、設定可能なコンソールキーマップを確認できます。 また
/usr/share/consolefonts
ディレクトリを見れば、設定可能なスクリーンフォントを確認できます。
/etc/vconsole.conf
ファイルの各行は
VARIABLE="value" といった書式により構成されます。 VARIABLE には以下の変数を利用します。
この変数はキーボードに対するキーマッピングテーブルを指定します。 これが定められていない場合はデフォルトで
us
が設定されます。
この変数は二番目のトグルキーマップを設定します。 デフォルトでは本変数は設定されません。
この変数は仮想コンソールにて用いられるフォントを指定します。
この変数はコンソールマップを指定します。
この変数は Unicode フォントマップを指定します。
ドイツのキーボードおよびコンソールの設定例は以下です。
cat > /etc/vconsole.conf << "EOF"
KEYMAP=de-latin1
FONT=Lat2-Terminus16
EOF
localectl ユーティリティーを用いれば、システム稼動中に KEYMAP 変数を変更することができます。
localectl set-keymap MAP
localectl コマンドは chroot 環境内では動作しない点に注意してください。 systemd を使って LFS システムを起動したときになって、初めて利用できるものです。
localectl ユーティリティーはまた、X11 キーボードレイアウト、モデル、ヴァリアント、オプションをそれぞれ対応する変数により設定することができます。
localectl set-x11-keymap LAYOUT [MODEL] [VARIANT] [OPTIONS]
localectl set-x11-keymap に対して設定可能な値の一覧は、以下の変数を使って localectl を実行して得ることができます。
X11 キーボードマッピングモデルを表示します。
X11 キーボードマッピングレイアウトを表示します。
X11 キーボードマッピングヴァリアントを表示します。
X11 キーボードマッピングオプションを表示します。
上に示す変数を利用するにあたっては BLFS ブックに説明する XKeyboard-Config パッケージが必要です。
以降に示す /etc/locale.conf
ファイルは言語を設定するために必要となる環境変数を定義します。 これを設定することによって以下の内容が定められます。
プログラムの出力結果を指定した言語で得ることができます。
キャラクターを英字、数字、その他のクラスに分類します。 この設定は、英語以外のロケールにおいて、コマンドラインに非アスキー文字が入力された場合に bash が正しく入力を受け付けるために必要となります。
各国ごとに正しくアルファベット順が並ぶようにします。
適切なデフォルト用紙サイズを設定します。
通貨、日付、時刻を正しい書式で出力するように設定します。
以下において <ll>
と示しているものは、言語を表す2文字の英字 (例えば 「en」) に、また <CC>
は、国を表す2文字の英字 (例えば
「GB」)
にそれぞれ置き換えてください。 <charmap>
は、選択したロケールに対応したキャラクターマップ (charmap) に置き換えてください。
オプションの修飾子として「@euro」といった記述もあります。
以下のコマンドを実行すれば Glibc が取り扱うロケールを一覧で見ることができます。
locale -a
キャラクターマップにはエイリアスがいくつもあります。 例えば「ISO-8859-1」は「iso8859-1」や「iso88591」として記述することもできます。
ただしアプリケーションによってはエイリアスを正しく取り扱うことができないものがあります。 (「UTF-8」
の場合、「UTF-8」と書かなければならず、これを「utf8」としてはならない場合があります。)
そこでロケールに対する正規の名称を選ぶのが最も無難です。 正規の名称は以下のコマンドを実行すれば分かります。 ここで
<locale name>
は
locale -a
コマンドの出力から得られたロケールを指定します。 (本書の例では「en_GB.iso88591」としています。)
LC_ALL=<locale name>
locale charmap
「en_GB.iso88591」ロケールの場合、上のコマンドの出力は以下となります。
ISO-8859-1
出力された結果が「en_GB.ISO-8859-1」に対するロケール設定として用いるべきものです。 こうして探し出したロケールは動作確認しておくことが重要です。 Bash の起動ファイルに記述するのはその後です。
LC_ALL=<locale name> locale language LC_ALL=<locale name> locale charmap LC_ALL=<locale name> locale int_curr_symbol LC_ALL=<locale name> locale int_prefix
上のコマンドを実行すると、言語名やロケールに応じたキャラクターエンコーディングが出力されます。 また通貨や各国ごとの国際電話番号プレフィックスも出力されます。 コマンドを実行した際に以下のようなメッセージが表示されたら、第 8 章にてロケールをインストールしていないか、あるいはそのロケールが Glibc のデフォルトのインストールではサポートされていないかのいずれかです。
locale: Cannot set LC_* to default locale: No such file or directory
このエラーが発生したら localedef コマンドを使って、目的とするロケールをインストールするか、別のロケールを選ぶ必要があります。 これ以降の説明では Glibc がこのようなエラーを生成していないことを前提に話を進めます。
LFS には含まれない他のパッケージにて、指定したロケールをサポートしていないものがあります。 例えば X ライブラリ (X ウィンドウシステムの一部) では、内部ファイルに指定されたキャラクターマップ名に合致しないロケールを利用した場合に、以下のようなメッセージを出力します。
Warning: locale not supported by Xlib, locale set to C
Xlib ではキャラクターマップはたいてい、英大文字とダッシュ記号を用いて表現されます。 例えば "iso88591" ではなく "ISO-8859-1" となります。 ロケール設定におけるキャラクターマップ部分を取り除いてみれば、適切なロケール設定を見出すことができます。 これはまた locale charmap コマンドを使って、設定を変えてみてロケールを指定してみれば確認できます。 例えば "de_DE.ISO-8859-15@euro" という設定を "de_DE@euro" に変えてみて Xlib がそのロケールを認識するかどうか確認してみてください。
これ以外のパッケージでも、パッケージが求めるものとは異なるロケール設定がなされた場合に、適切に処理されないケースがあります。 (そして必ずしもエラーメッセージが表示されない場合もあります。) そういったケースでは、利用している Linux ディストリビューションがどのようにロケール設定をサポートしているかを調べてみると、有用な情報が得られるかもしれません。
適切なロケール設定が決まったら /etc/locale.conf
ファイルを生成します。
cat > /etc/locale.conf << "EOF"
LANG=<ll>_<CC>.<charmap><@modifiers>
EOF
/etc/locale.conf
ファイルは systemd
のユーティリティープログラム localectl を使って定めることもできます。
例えば上と同じ設定を行うには以下を実行します。
localectl set-locale LANG="<ll>_<CC>.<charmap><@modifiers>
"
言語に関連する環境変数、例えば LANG
, LC_CTYPE
, LC_NUMERIC
などや、locale
が出力する環境変数を指定することもできます。 その場合は各設定をスペースにより区切ります。 例として LANG
を en_US.UTF-8 とし LC_CTYPE
を単に en_US とする場合は以下のようにします。
localectl set-locale LANG="en_US.UTF-8" LC_CTYPE="en_US"
localectl コマンドは chroot 環境内では動作しない点に注意してください。 systemd を使って LFS システムを起動したときになって、初めて利用できるものです。
ロケール設定の「C」(デフォルト) と「en_US」(米国の英語利用ユーザーに推奨) は異なります。 「C」は US-ASCII 7 ビットキャラクターセットを用います。 もし最上位ビットがセットされたキャラクターがあれば不適当なものとして取り扱います。 例えば ls コマンドにおいてクエスチョン記号が表示されることがあるのはこのためです。 また Mutt や Pine などにより電子メールが送信される際に、そういった文字は RFC には適合しないメールとして送信されます。 送信された文字は「不明な 8ビット (unknown 8-bit)」として示されます。 そこで 8ビット文字を必要としないことが明らかな場合には「C」ロケールを指定してください。
inputrc
ファイルは readline
ライブラリに対する設定ファイルです。 この Readline
ライブラリは、ユーザーが端末から文字列入力を行う際の編集機能を提供するものです。
キーボード入力内容は所定の処理動作に変換され解釈されます。 readline ライブラリは bash
をはじめとする各種シェルや他の多くのアプリケーションにおいて利用されています。
ユーザー固有の機能を必要となるのはまれなので、以下の /etc/inputrc
ファイルによって、ログインユーザーすべてに共通するグローバルな定義を生成します。
各ユーザーごとにこのデフォルト定義を上書きする必要が出てきた場合は、ユーザーのホームディレクトリに .inputrc
ファイルを生成して、修正マップを定義することもできます。
inputrc
ファイルの設定方法については
info bash
により表示される Readline Init
File の節に詳しい説明があります。 info readline にも有用な情報があります。
以下はグローバルな inputrc
ファイルの一般的な定義例です。
コメントをつけて各オプションを説明しています。 コメントはコマンドと同一行に記述することはできません。
以下のコマンドを実行してこのファイルを生成します。
cat > /etc/inputrc << "EOF"
# Begin /etc/inputrc
# Modified by Chris Lynn <roryo@roryo.dynup.net>
# Allow the command prompt to wrap to the next line
set horizontal-scroll-mode Off
# Enable 8-bit input
set meta-flag On
set input-meta On
# Turns off 8th bit stripping
set convert-meta Off
# Keep the 8th bit for display
set output-meta On
# none, visible or audible
set bell-style none
# All of the following map the escape sequence of the value
# contained in the 1st argument to the readline specific functions
"\eOd": backward-word
"\eOc": forward-word
# for linux console
"\e[1~": beginning-of-line
"\e[4~": end-of-line
"\e[5~": beginning-of-history
"\e[6~": end-of-history
"\e[3~": delete-char
"\e[2~": quoted-insert
# for xterm
"\eOH": beginning-of-line
"\eOF": end-of-line
# for Konsole
"\e[H": beginning-of-line
"\e[F": end-of-line
# End /etc/inputrc
EOF
shells
ファイルには、システム上でのログインシェルを記述します。
各アプリケーションはこのファイルを参照して、シェルが適切であるかどうかを判別します。
各シェルの指定は1行で行い、そのシェルのパスを記述します。 パスはルートディレクトリ (/) を基準として記述します。
例えば一般ユーザーが自身のアカウントに対するログインシェルを chsh にしようとした場合、chsh が
shells
ファイルを参照します。
シェルコマンド名が記述されていなければ、その一般ユーザーはシェルの変更ができません。
例えば GDM は /etc/shells
ファイルが参照できない時には対話インターフェースの設定が出来ません。 また FTP
デーモンなどは、このファイルに記述されていないシェルを用いてのユーザーアクセスを拒否するのが通常です。
こういったアプリケーションのためにこのファイルが必要となります。
cat > /etc/shells << "EOF"
# Begin /etc/shells
/bin/sh
/bin/bash
# End /etc/shells
EOF
/etc/systemd/system.conf
ファイルには、基本的な systemd 動作を制御するための設定オプション項目があります。
デフォルトのファイルは、各項目のデフォルト値が示された上でそれがコメントアウトされています。
このファイルでは基本的なジャーナル設定やログレベルを設定する必要があります。 各オプションの詳細については man ページ
systemd-system.conf(5)
を参照してください。
通常 systemd はブート処理の最後に画面をクリアします。 必要ならばこの動きを以下のようにして変更することができます。
mkdir -pv /etc/systemd/system/getty@tty1.service.d
cat > /etc/systemd/system/getty@tty1.service.d/noclear.conf << EOF
[Service]
TTYVTDisallocate=no
EOF
ブートメッセージは、root
ユーザーになってコマンド
journalctl -b
を実行することで、常に表示しておくこともできます。
デフォルトでは /tmp
は tmpfs として生成されます。
これが適当ではないならば、以下のコマンドによりオーバーライドすることができます。
ln -sfv /dev/null /etc/systemd/system/tmp.mount
それとは別に /tmp
を別パーティションとする場合は、/etc/fstab
にそのパーティションを指定します。
/tmp
を別パーティションとした場合、このパーティションに対してシンボリックリンクを作成することは避けてください。
これを行ってしまうと、ルートファイルシステム(/)を r/w
として再マウントすることができなくなり、システムを再起動すると利用できなくなります。
ファイルやディレクトリを生成、削除するサービスがいくつかあります。
systemd-tmpfiles-clean.service
systemd-tmpfiles-setup-dev.service
systemd-tmpfiles-setup.service
システム用設定ファイルは /usr/lib/tmpfiles.d/*.conf
です。 ローカル用設定ファイルは
/etc/tmpfiles.d/*.conf
に置きます。
/etc/tmpfiles.d
にあるファイルは
/usr/lib/tmpfiles.d
にある同名ファイルをオーバーライドします。 ファイル書式の詳細については man ページ tmpfiles.d(5)
を参照してください。
/usr/lib/tmpfiles.d/*.conf
ファイルの文法はやっかいなものです。 例えば /tmp ディレクトリ内のファイルを消去するためのデフォルト設定は
/usr/lib/tmpfiles.d/tmp.conf
ファイルに以下のように記述されます。
q /tmp 1777 root root 10d
型を表わす q はクォータを用いたサブボリュームを生成するものとして説明されています。 ただこれが適用できるのは btrfs ファイルシステムのみです。 この型は v を参照し、次に d(ディレクトリ)を参照します。 指定されたディレクトリが存在しない場合はそれが生成されて、パーミッションと所有者が指定されたものに設定されます。 時間指定が行われた場合、そのディレクトリ内のファイルは、それに応じて削除されます。
デフォルトパラーメーターを必要としない場合は、設定ファイルを /etc/tmpfiles.d
にコピーして必要な設定を行っておきます。
例えば以下です。
mkdir -p /etc/tmpfiles.d cp /usr/lib/tmpfiles.d/tmp.conf /etc/tmpfiles.d
ユニットパラメーターをオーバーライドするには /etc/systemd/system
ディレクトリを生成して設定ファイルを作成します。 例えば以下のとおりです。
mkdir -pv /etc/systemd/system/foobar.service.d
cat > /etc/systemd/system/foobar.service.d/foobar.conf << EOF
[Service]
Restart=always
RestartSec=30
EOF
詳しくは man ページ systemd.unit(5)
を参照してください。 設定ファイルを作成したら systemctl daemon-reload
と
systemctl restart
foobar
を実行します。 これによりサービスの設定内容が反映されます。
SysVinit や BSD スタイルの起動システムにおいては単純なシェルスクリプトが用いられていますが、 systemd ではさまざまな形式の起動ファイル (あるいはユニット) を統一化するフォーマットが用いられています。 systemctl コマンドがユニットファイルの有効/無効、状態制御/参照を行います。 以下に示すものがよく用いられます。
systemctl list-units -t
<service>
[--all]: サービスタイプのユニットファイルをロードします。
systemctl list-units -t
<target>
[--all]: ターゲットタイプのユニットファイルをロードします。
systemctl show -p Wants
<multi-user.target>
:
マルチユーザーターゲットに依存するユニットをすべて表示します。
ターゲットは特別なユニットファイルであり、SysVinit におけるランレベルに相当します。
systemctl status
<servicename.service>
:
servicename で示されるサービスの状態を表示します。 拡張子 .service
は、他に同名のサービスがない限り、例えば .socket ファイルであるような場合は省略することができます。
(.socket ファイルは inetd/xinetd と同様の機能を提供するソケットを生成します。)
systemd により起動したシステムのシステムログは、従来の unix syslog デーモンとは異なり、デフォルトで systemd-journald により扱われます。 必要に応じて標準的な syslog デーモンを追加することも可能で、両者を併用することもできます。 systemd-journald プログラムはジャーナル項目を保存しますが、それはテキストログファイルではなく、バイナリフォーマットファイルです。 そのファイル内容を確認するために journalctl コマンドが提供されています。 以下に示すものがよく用いられます。
journalctl -r: ジャーナル項目すべてを日付の昇順により表示します。
journalctl -u UNIT
:
指定された UNIT ファイルに関連したジャーナル項目を表示します。
journalctl -b[=ID] -r: 直近の起動成功から (あるいはブートIDから) のジャーナル項目を、日付の昇順により表示します。
journalctl -f: tail -f と同様の機能を提供します。
クラッシュしたプログラムをデバッグするのに、コアダンプというものが重宝します。
特にデーモンプロセスがクラッシュした場合です。 systemd によるブートシステムにおいて、コアダンプは
systemd-coredump が取り扱います。
このプログラムはジャーナル内にコアダンプのログを出力し、コアダンプそのものは /var/lib/systemd/coredump
に保存します。
コアダンプを取り出して処理するために coredumpctl
というツールが提供されています。 よく利用されるコマンド例を以下に示します。
coredumpctl -r: すべてのコアダンプを新しい順に一覧表示します。
coredumpctl -1 info: 最新のコアダンプの情報を表示します。
coredumpctl -1 debug: 最新のコアダンプを GDB にロードします。
コアダンプはディスク容量を大量に消費することがあります。 /etc/systemd/coredump.conf.d
に設定ファイルを生成して、
コアダンプに利用するディスク容量の最大を制御することができます。 たとえば以下のとおりです。
mkdir -pv /etc/systemd/coredump.conf.d
cat > /etc/systemd/coredump.conf.d/maxuse.conf << EOF
[Coredump]
MaxUse=5G
EOF
詳細は systemd-coredump(8)
,
coredumpctl(1)
, coredump.conf.d(5)
の各 man ページを参照してください。
systemd-230 より取り入れられた機能として、ユーザープロセスは、たとえ nohup が用いられたり、あるいは
daemon()
や setsid()
が利用されたプロセスであっても、ユーザーセッションが終了するとともに終了します。
この機能変更は、従来からの柔軟な実装を厳格なものとする意図で行われたものです。
したがって稼動し続けるプロセスが利用されていると (例えば screen や tmux
など)、この機能変更が問題を引き起こすことになるかもしれません。
つまりユーザーセッションが終了した後にもプロセスをアクティブにしておくことが必要になります。
ユーザーセッション終了後にプロセスを継続させる方法として、以下の三つの方法があります。
指定ユーザーのプロセスを継続させる方法:
標準的なユーザーは自身のユーザー権限においてコマンド loginctl
enable-linger を実行して、プロセスを継続させることができます。
システム管理者は user
引数を利用して、そのユーザーに対して同一のコマンドを実行可能です。 そしてそのユーザーは
systemd-run
コマンドを実行することでプロセスを継続的に稼動させます。 例えば systemd-run --scope --user
/usr/bin/screen などとします。
特定ユーザーに対してのプロセス継続を行った場合、ログインセッションがすべて終了しても
user@.service が残ります。 そしてこれはシステム起動時にも自動実行されます。
つまりユーザーセッションが終了した後にもプロセスの有効無効の制御が明示的に行えるものであり、nohup
や deamon()
を利用するユーティリティーなどの下位互換性をなくすものです。
システムワイドなプロセスを継続させる方法:
/etc/systemd/logind.conf
ファイル内に KillUserProcesses=no
を指定すれば、全ユーザーに対してグローバルにプロセスを継続起動させることができます。
これは明示的に制御する方法を無用とし、従来どおり全ユーザーに対しての方式を残すメリットがあります。
機能変更をビルド時に無効化する方法:
プロセス継続をデフォルトとするために systemd のビルド時に meson コマンドにおいて
-Ddefault-kill-user-processes=false
スイッチを指定する方法があります。 この方法をとれば、systemd
がセッション終了時にユーザープロセスを終了させてしまう機能を完全に無効化することができます。
ここからは LFS システムをブート可能にしていきます。 この章では /etc/fstab
ファイルを作成し、LFS システムのカーネルを構築します。 また
GRUB のブートローダーをインストールして LFS システムの起動時にブートローダーを選択できるようにします。
/etc/fstab
ファイルは、種々のプログラムがファイルシステムのマウント状況を確認するために利用するファイルです。
ファイルシステムがデフォルトでどこにマウントされ、それがどういう順序であるか、マウント前に (整合性エラーなどの)
チェックを行うかどうか、という設定が行われます。 新しいファイルシステムに対する設定は以下のようにして生成します。
cat > /etc/fstab << "EOF"
# Begin /etc/fstab
# file system mount-point type options dump fsck
# order
/dev/<xxx>
/ <fff>
defaults 1 1
/dev/<yyy>
swap swap pri=1 0 0
# End /etc/fstab
EOF
<xxx>
、
<yyy>
、
<fff>
の部分はシステムに合わせて正しい記述に書き換えてください。 例えば sda2
、sda5
、ext4
といったものです。 上記各行の6項目の記述内容については man
5 fstab により確認してください。
MS-DOS や Windows において利用されるファイルシステム(つまり
vfat、ntfs、smbfs、cifs、iso9660、udfなど)では、ファイル名称内に用いられた非アスキー文字を正しく認識させるために、特別なマウントオプション「utf8」の指定が必要になります。
UTF-8 以外のロケールの場合 iocharset
オプションには、文字ロケールと同じ値を設定することが必要であり、カーネルが理解できる形でなければなりません。
またこれを動作させるために、対応するキャラクターセット定義(File systems ->Native Language
Support にあります)をカーネルに組み入れるか、モジュールとしてビルドすることが必要です。 ただし
iocharset=utf8
というオプション指定によって文字ロケールを UTF-8
とした場合、ファイルシステムの英大文字小文字は区別されるようになります。 これを避けるのであれば、iocharset=utf8
ではなく特別なオプション utf8
を指定します。 vfat や smbfs
ファイルシステムを用いるなら、さらに「codepage」オプションも必要です。 このオプションには、国情報に基づいて
MS-DOS にて用いられるコードページ番号をセットします。 例えば USB フラッシュドライブをマウントし
ru_RU.KOI8-R をセットするユーザーであれば /etc/fstab
ファイルの設定は以下のようになります。
noauto,user,quiet,showexec,codepage=866,iocharset=koi8r
ru_RU.UTF-8 をセットするなら以下のように変わります。
noauto,user,quiet,showexec,codepage=866,utf8
iocharset
オプションは iso8859-1
に対してのデフォルト設定です。
(その場合、ファイルシステムの英大文字小文字は区別されません。) utf8
オプションは、ファイル名称が UTF-8
ロケール内にて正しく認識されるように、カーネルが UTF-8 ロケールに変換して取り扱うことを指示するものです。
ファイルシステムによっては codepage と iocharset のデフォルト値をカーネルにおいて設定することもできます。
カーネルにおいて対応する設定は「Default
NLS Option」(CONFIG_NLS_DEFAULT)
、「Default Remote NLS
Option」(CONFIG_SMB_NLS_DEFAULT
)、「Default codepage for
FAT」(CONFIG_FAT_DEFAULT_CODEPAGE
)、「Default iocharset for
FAT」(CONFIG_FAT_DEFAULT_IOCHARSET
) です。 なお ntfs
ファイルシステムに対しては、カーネルのコンパイル時に設定する項目はありません。
特定のハードディスクにおいて ext3 ファイルシステムでの電源供給不足時の信頼性を向上させることができます。 これは
/etc/fstab
での定義においてマウントオプション
barrier=1
を指定します。
ハードディスクがこのオプションをサポートしているかどうかは
hdparm を実行することで確認できます。 例えば以下のコマンドを実行します。
hdparm -I /dev/sda | grep NCQ
何かが出力されたら、このオプションがサポートされていることを意味します。
論理ボリュームマネージャー (Logical Volume Management; LVM) に基づいたパーティションでは
barrier
オプションは利用できません。
Linux パッケージは Linux カーネルを提供します。
カーネルの構築は、カーネルの設定、コンパイル、インストールの順に行っていきます。
本書が行っているカーネル設定の方法以外については、カーネルソースツリー内にある README
ファイルを参照してください。
コンパイルするための準備として以下のコマンドを実行します。
make mrproper
これによりカーネルソースが完全にクリーンなものになります。 カーネル開発チームは、カーネルコンパイルするなら、そのたびにこれを実行することを推奨しています。 tar コマンドにより伸張しただけのソースではクリーンなものにはなりません。
カーネルオプションの設定方法にはいくつかあります。 通常は以下に示すように、メニュー形式のインターフェースを通じて行います。
make menuconfig
追加する make 環境変数の意味:
LANG=<host_LANG_value>
LC_ALL=
これはホストのロケール設定を指示するものです。 この設定は UTF-8 での表示設定がされたテキストコンソールにて menuconfig の ncurses による行表示を適切に行うために必要となります。
<host_LANG_value>
の部分は、ホストの $LANG
変数の値に置き換えてください。 $LC_ALL
あるいは
$LC_CTYPE
の値を設定することもできます。
これは ncurses によるメニュー形式のインターフェースを起動します。 これ以外の(グラフィカルな)インターフェースについては make help を入力して確認してください。
カーネルの設定方法に関する一般的な情報が https://www.linuxfromscratch.org/hints/downloads/files/kernel-configuration.txt にあるので参照してください。 BLFS では LFS が取り扱わない各種パッケージに対して、必要となるカーネル設定項目を説明しています。 https://www.linuxfromscratch.org/blfs/view/stable-systemd/longindex.html#kernel-config-index を参照してください。 さらに詳しくカーネルの構築や設定を説明している http://www.kroah.com/lkn/ もあります。
カーネル設定を行うにあたって、分かりやすいやり方として make defconfig を実行する方法があります。 これを実行することで基本的な設定がなされ、現在のシステム構成が考慮された、より良い設定が得られるかもしれません。
以下の機能項目についての有効、無効、設定状況を確認してください。 不適切である場合にはシステムが正常動作しなかったり起動できなかったりするかもしれません。
General setup --> [ ] Compile the kernel with warnings as errors [CONFIG_WERROR] [ ] Auditing Support [CONFIG_AUDIT] CPU/Task time and stats accounting ---> [*] Pressure stall information tracking [CONFIG_PSI] < > Enable kernel headers through /sys/kernel/kheaders.tar.xz [CONFIG_IKHEADERS] [*] Control Group support [CONFIG_CGROUPS] ---> [*] Memory controller [CONFIG_MEMCG] [ ] Enable deprecated sysfs features to support old userspace tools [CONFIG_SYSFS_DEPRECATED] [*] Configure standard kernel features (expert users) [CONFIG_EXPERT] ---> [*] open by fhandle syscalls [CONFIG_FHANDLE] General architecture-dependent options ---> [*] Enable seccomp to safely compute untrusted bytecode [CONFIG_SECCOMP] Networking support ---> Networking options ---> <*> The IPv6 protocol [CONFIG_IPV6] Device Drivers ---> Generic Driver Options ---> [ ] Support for uevent helper [CONFIG_UEVENT_HELPER] [*] Maintain a devtmpfs filesystem to mount at /dev [CONFIG_DEVTMPFS] [*] Automount devtmpfs at /dev, after the kernel mounted the rootfs [CONFIG_DEVTMPFS_MOUNT] Firmware Loader ---> [ ] Enable the firmware sysfs fallback mechanism [CONFIG_FW_LOADER_USER_HELPER] Firmware Drivers ---> [*] Export DMI identification via sysfs to userspace [CONFIG_DMIID] Graphics support ---> Frame buffer Devices ---> <*> Support for frame buffer devices ---> File systems ---> [*] Inotify support for userspace [CONFIG_INOTIFY_USER] Pseudo filesystems ---> [*] Tmpfs POSIX Access Control Lists [CONFIG_TMPFS_POSIX_ACL]
64 ビットシステムの構築時は、追加機能をいくらか有効にしてください。 menuconfig
を利用している場合、初めに CONFIG_PCI_MSI
を有効にして、その後に
CONFIG_IRQ_REMAP
、CONFIG_X86_X2APIC
を有効にします。
こうするのは、依存するオプションが選択されていないと、特定のオプションが現れてこないからです。
Processor type and features ---> [*] Support x2apic [CONFIG_X86_X2APIC] Memory Management options ---> [ ] Enable userfaultfd() system call [CONFIG_USERFAULTFD] Device Drivers ---> [*] PCI Support ---> [CONFIG_PCI] [*] Message Signaled Interrupts (MSI and MSI-X) [CONFIG_PCI_MSI] [*] IOMMU Hardware Support ---> [CONFIG_IOMMU_SUPPORT] [*] Support for Interrupt Remapping [CONFIG_IRQ_REMAP]
"The IPv6 Protocol" については厳密には不要としても良いものですが、システム開発者は強く推奨しているものです。
ホストが UEFI を利用していて、これを使って LFS システムのブートを行いたい場合は、 BLFS ページ に従って、カーネル設定を調整する必要があります。
上の設定項目の説明
Compile
the kernel with warnings as errors
これを設定すると、カーネル開発者が採用するコンパイラーや設定と異なる場合に、カーネルビルドエラーとなる場合があります。
Enable
kernel headers through
/sys/kernel/kheaders.tar.xz
これは、 カーネルビルドにあたって cpio を必要とします。 cpio は LFS ではインストールしません。
Support
for uevent helper
本項目を有効にすることで、デバイス管理を Udev/Eudev により行ないます。
Maintain a
devtmpfs
本項目は、カーネルにより事前登録される自動化デバイスノードを生成します。 これは Udev が動作していなくても行われます。 Udev はその上で起動し、パーミッション管理やシンボリックリンクの追加を行います。 Udev/Eudev を利用する場合には本項目を有効にすることが必要です。
Automount
devtmpfs at /dev
これは、カーネルから見たデバイス情報を /dev 上にマウントするものです。 init が起動される直前にルートファイルシステムに切り替えられます。
Support
x2apic
64 ビット x86 プロセッサーの x2APIC モードでのインタラプトコントローラーの実行をサポートします。 64 ビット x86 システムにおいてはファームウェアが x2APIC を有効にすることがあります。 ファームウェアによって x2APIC が有効である場合、カーネルにおいてこのオプションが無効であると、起動時にパニックを起こします。 本オプションには効果がありません。 またファームウェアによって x2APIC が無効であった場合、このオプションは影響を及ぼしません。
Enable
userfaultfd() system call
このオプションを有効にすると、Linux-5.19.2 において解決されていないセキュリティぜい弱性が悪用される危険があります。 ぜい弱性を避けるために、このオプションは無効にしてください。 このシステムコールは LFS や BLFS のどこからも利用しません。
上のコマンドではなく、状況によっては make
oldconfig を実行することが適当な場合もあります。
詳細についてはカーネルソース内の README
ファイルを参照してください。
カーネル設定は行わずに、ホストシステムにあるカーネル設定ファイル .config
をコピーして利用することもできます。
そのファイルが存在すればの話です。 その場合は linux-5.19.2
ディレクトリにそのファイルをコピーしてください。
もっともこのやり方はお勧めしません。
設定項目をメニューから探し出して、カーネル設定を一から行っていくことが望ましいことです。
カーネルイメージとモジュールをコンパイルします。
make
カーネルモジュールを利用する場合 /etc/modprobe.d
ディレクトリ内での設定を必要とします。
モジュールやカーネル設定に関する情報は 「デバイスとモジュールの扱いについて」や
linux-5.19.2/Documentation
ディレクトリにあるカーネルドキュメントを参照してください。 また modprobe.d(5)
も有用です。
カーネル設定においてモジュールの利用を無効にしているのでなければ、ここでモジュールをインストールします。
make modules_install
カーネルのコンパイルが終わったら、インストールの完了に向けてあと少し作業を行います。 /boot
ディレクトリにいくつかのファイルをコピーします。
ホストシステムが独立した /boot パーティションを用いている場合はファイルをそこにコピーします。
これを簡単に行うために、作業前に(chroot 前の)/boot をホストの /mnt/lfs/boot
にバインドしておく方法があります。 ホストシステム の root
ユーザーとなって以下を実行します。
mount --bind /boot /mnt/lfs/boot
カーネルイメージへのパスは、利用しているプラットフォームによってさまざまです。 そのファイル名は、好みにより自由に変更して構いません。 ただし vmlinuz という語は必ず含めてください。 これにより、次節で説明するブートプロセスを自動的に設定するために必要なことです。 以下のコマンドは x86 アーキテクチャーの場合の例です。
cp -iv arch/x86/boot/bzImage /boot/vmlinuz-5.19.2-lfs-11.2-systemd
System.map
はカーネルに対するシンボルファイルです。
このファイルはカーネル API の各関数のエントリポイントをマッピングしています。
同様に実行中のカーネルのデータ構成のアドレスを保持します。
このファイルは、カーネルに問題があった場合にその状況を調べる手段として利用できます。
マップファイルをインストールするには以下を実行します。
cp -iv System.map /boot/System.map-5.19.2
カーネル設定ファイル .config
は、上で実行した
make menuconfig
によって生成されます。 このファイル内には、今コンパイルしたカーネルの設定項目の情報がすべて保持されています。
将来このファイルを参照する必要が出てくるかもしれないため、このファイルを保存しておきます。
cp -iv .config /boot/config-5.19.2
Linux カーネルのドキュメントをインストールします。
install -d /usr/share/doc/linux-5.19.2 cp -r Documentation/* /usr/share/doc/linux-5.19.2
カーネルのソースディレクトリは所有者が root ユーザーになっていません。 我々は chroot 環境内の root ユーザーとなってパッケージを展開してきましたが、展開されたファイル類はパッケージ開発者が用いていたユーザー ID、グループ ID が適用されています。 このことは普通はあまり問題になりません。 というのもパッケージをインストールした後のソースファイルは、たいていは削除するからです。 一方 Linux のソースファイルは、削除せずに保持しておくことがよく行われます。 このことがあるため開発者の用いたユーザーIDが、インストールしたマシン内の誰かの ID に割り当たった状態となりえます。 その人はカーネルソースを自由に書き換えてしまう権限を持つことになるわけです。
カーネルの設定は、BLFS をインストールしていくにつれて、設定を更新していかなければならないことが多々あります。 一般にパッケージのソースは削除することが通常ですが、カーネルのソースに関しては、カーネルをもう一度新たにインストールするなら、削除しなくて構いません。
カーネルのソースファイルを保持しておくつもりなら linux-5.19.2
ディレクトリにおいて chown -R 0:0
を実行しておいてください。 これによりそのディレクトリの所有者は root ユーザーとなります。
カーネルを説明する書の中には、カーネルのソースディレクトリに対してシンボリックリンク /usr/src/linux
の生成を勧めているものがあります。 これはカーネル
2.6 系以前におけるものであり LFS システム上では生成してはなりません 。 ベースとなる LFS
システムを構築し、そこに新たなパッケージを追加していこうとした際に、そのことが問題となるからです。
さらに include
ディレクトリ
(/usr/include
)
にあるヘッダーファイルは、必ず
Glibc のコンパイル時のものでなければなりません。 つまり 「Linux-5.19.2 API ヘッダー」
によってインストールされた、健全化 (sanitizing) したものです。
したがって生のカーネルヘッダーや他のカーネルにて健全化されたヘッダーによって上書きされてしまうのは避けなければなりません。
たいていの場合 Linux モジュールは自動的にロードされます。 しかし中には特定の指示を必要とするものもあります。
モジュールをロードするプログラム、modprobe または insmod は、そのような指示を行う目的で
/etc/modprobe.d/usb.conf
を利用します。 USB ドライバー (ehci_hcd, ohci_hcd, uhci_hcd)
がモジュールとしてビルドされていた場合には、それらを正しい順でロードしなければならず、そのために /etc/modprobe.d/usb.conf
ファイルが必要となります。
ehci_hcd は ohci_hcd や uhci_hcd よりも先にロードしなければなりません。
これを行わないとブート時に警告メッセージが出力されます。
以下のコマンドを実行して /etc/modprobe.d/usb.conf
ファイルを生成します。
install -v -m755 -d /etc/modprobe.d
cat > /etc/modprobe.d/usb.conf << "EOF"
# Begin /etc/modprobe.d/usb.conf
install ohci_hcd /sbin/modprobe ehci_hcd ; /sbin/modprobe -i ohci_hcd ; true
install uhci_hcd /sbin/modprobe ehci_hcd ; /sbin/modprobe -i uhci_hcd ; true
# End /etc/modprobe.d/usb.conf
EOF
カーネルの設定をすべて含みます。 |
|
Linux システムのエンジンです。 コンピューターを起動した際には、オペレーティングシステム内にて最初にロードされるものです。 カーネルはコンピューターのハードウェアを構成するあらゆるコンポーネントを検知して初期化します。 そしてそれらのコンポーネントをツリー階層のファイルとして、ソフトウェアが利用できるようにします。 ただひとつの CPU からマルチタスクを処理するマシンとして、あたかも多数のプログラムが同時稼動しているように仕向けます。 |
|
アドレスとシンボルのリストです。 カーネル内のすべての関数とデータ構成のエントリポイントおよびアドレスを示します。 |
UEFI サポートが有効なシステムにおいて UEFI を使って LFS をブートしたい場合は、本ページは読み飛ばしてください。 そして BLFS ページ に示されている手順に従って、UEFI に対応するように GRUB 設定を行ってください。
GRUB の設定を誤ってしまうと、CD-ROM や USB 起動ドライブのような他のデバイスからもブートできなくなってしまいます。 読者の LFS システムをブート可能とするためには、本節の内容は必ずしも必要ではありません。 読者が利用している現在のブートローダー、例えば Grub-Legacy, GRUB2, LILO などの設定を修正することが必要かもしれません。
コンピューターが利用不能に (ブート不能に) なってしまうこともあります。
そんな事態に備えてコンピューターを「復旧
(resucue)」するブートディスクの生成を必ず行ってください。
ブートデバイスを用意していない場合は作成してください。 以降に示す手順を実施するために、必要に応じて BLFS
ブックを参照し
libisoburn にある xorriso
をインストールしてください。
cd /tmp grub-mkrescue --output=grub-img.iso xorriso -as cdrecord -v dev=/dev/cdrw blank=as_needed grub-img.iso
GRUB ではドライブやパーティションに対して (hdn,m) といった書式の命名法を採用しています。
n
はハードドライブ番号、m
はパーティション番号を表します。 ハードドライブ番号はゼロから数え始めます。
一方パーティション番号は、基本パーティションであれば1から、拡張パーティションであれば5から数え始めます。
かつてのバージョンでは共にゼロから数え始めていましたが、今はそうではないので注意してください。 例えば
sda1
は GRUB では (hd0,1) と表記され、sdb3
は (hd1,3) と表記されます。 Linux
システムでの取り扱いとは違って GRUB では CD-ROM ドライブをハードドライブとしては扱いません。 例えば CD
が hdb
であり、2番めのハードドライブが
hdc
であった場合、2番めのハードドライブは
(hd1) と表記されます。
GRUB は、ハードディスク上の最初の物理トラックにデータを書き出します。 この領域は、どのファイルシステムにも属していません。 ここに配置されているプログラムは、ブートパーティションにある GRUB モジュールにアクセスします。 モジュールのデフォルト位置は /boot/grub/ です。
ブートパーティションをどこにするかは各人に委ねられていて、それによって設定方法が変わります。
推奨される1つの手順としては、ブートパーティションとして独立した小さな (200MB 程度のサイズの)
パーティションを設けることです。 こうしておくと、この後に LFS
であろうが商用ディストリビューションであろうが、システム導入する際に同一のブートファイルを利用することが可能です。
つまりどのようなブートシステムからでもアクセスが可能となります。
この方法をとるなら、新たなパーティションをマウントした上で、現在 /boot
ディレクトリにある全ファイルを (例えば前節にてビルドした Linux
カーネルも) 新しいパーティションに移動させる必要があります。 そしていったんパーティションをアンマウントし、再度
/boot
としてマウントしなおすことになります。
これを行った後は/etc/fstab
を適切に書き換えてください。
現時点での LFS パーティションでも問題なく動作します。 ただし複数システムを取り扱うための設定は、より複雑になります。
ここまでの情報に基づいて、ルートパーティションの名称を
(あるいはブートパーティションを別パーティションとするならそれも含めて) 決定します。
以下では例として、ルートパーティション (あるいは別立てのブートパーティション) が sda2
であるとします。
以下を実行して GRUB ファイル類を /boot/grub
にインストールし、ブートトラックを構築します。
以下に示すコマンドを実行すると、現在のブートローダーを上書きします。 上書きするのが不適当であるならコマンドを実行しないでください。 例えばマスターブートレコード (Master Boot Record; MBR) を管理するサードパーティ製のブートマネージャーソフトウェアを利用している場合などがこれに該当します。
grub-install /dev/sda
システムが UEFI を通じて起動されている時、grub-install は
x86_64-efi
ターゲットに対するファイルをインストールしようとします。 しかしそのようなファイルは 第 8 章 にてインストールしていません。
その場合は上のコマンドに対して --target
i386-pc
を追加してください。
/boot/grub/grub.cfg
ファイルを生成します。
cat > /boot/grub/grub.cfg << "EOF"
# Begin /boot/grub/grub.cfg
set default=0
set timeout=5
insmod ext2
set root=(hd0,2)
menuentry "GNU/Linux, Linux 5.19.2-lfs-11.2-systemd" {
linux /boot/vmlinuz-5.19.2-lfs-11.2-systemd root=/dev/sda2 ro
}
EOF
GRUB にとってカーネルファイル群は、配置されるパーティションからの相対位置となります。 したがって /boot パーティションを別に作成している場合は、上記の linux の行から /boot の記述を取り除いてください。 また set root 行でのブートパーティションの指定も、正しく設定する必要があります。
GRUB のパーティション指示子は、(USB
サムデバイスといったリムーバルディスクを含め)ディスクの加除によって変わることがあります。
その加除が原因で起動に失敗することがありますが、それは grub.cfg
において「古い」指示子を用いているからです。
こういった問題を避けようとおもったら、パーティション指定にあたって GRUB
指定子を用いずに、パーティションやファイルシステムの UUID を用いることが考えられます。 lsblk -o
UUID,PARTUUID,PATH,MOUNTPOINT を実行してください。
ファイルシステムの UUID が UUID
列に示されます。
またパーティションは PARTUUID
列に示されます。
そうしたら set root=(hdx,y)
の記述を
search --set=root --fs-uuid
に書き換え、同様に <カーネルがインストールされているファイルシステムの
UUID>
root=/dev/sda2
を root=PARTUUID=
に書き換えます。
<LFS がビルドされたパーティションの
UUID>
パーティションの UUID と、そのパーティション内のファイルシステムの UUID は全く異なります。
オンラインから得られる情報において、root=PARTUUID=
ではなく <パーティション UUID>
root=UUID=
を用いるように説明している場合があります。 これを行うには
initramfs が必要であり、これは LFS の範囲を超えるものです。
<ファイルシステム
UUID>
/dev
内のパーティションに対するデバイスノード名も変わります(GRUB 指定子が変更される可能性よりは低いです)。
/etc/fstab
において記述するデバイスノードへのパスは、たとえば /dev/sda1
を PARTUUID=
に置き換えることができます。
これによりデバイスノード名が変更になった場合の、潜在的な起動エラーを回避することができます。
<パーティション UUID>
GRUB は大変強力なプログラムであり、ブート処理に際しての非常に多くのオプションを提供しています。 これにより、各種デバイス、オペレーティングシステム、パーティションタイプに幅広く対応しています。 さらにカスタマイズのためのオプションも多く提供されていて、グラフィカルなスプラッシュ画面、サウンド、マウス入力などについてカスタマイズが可能です。 オプションの細かな説明は、ここでの手順説明の範囲を超えるため割愛します。
grub-mkconfig というコマンドは、設定ファイルを自動的に生成するものです。 このコマンドは /etc/grub.d/ にある一連のスクリプトを利用しており、それまでに設定していた内容は失われることになります。 その一連のスクリプトは、ソースコードを提供しない Linux ディストリビューションにて用いられるのが主であるため、LFS では推奨されません。 商用 Linux ディストリビューションをインストールする場合には、それらのスクリプトを実行する、ちょうど良い機会となるはずです。 こういった状況ですから、grub.cfg のバックアップは忘れずに行うようにしてください。
できました! LFS システムのインストール終了です。 あなたの輝かしいカスタムメイドの Linux システムが完成したことでしょう。
/etc/lfs-release
というファイルをここで作成することにします。 このファイルを作っておけば、どのバージョンの LFS
をインストールしたのか、すぐに判別できます。 (もしあなたが質問を投げた時には、我々もすぐに判別できることになります。)
以下のコマンドによりこのファイルを生成します。
echo 11.2-systemd > /etc/lfs-release
インストールシステムの情報を表わした 2 つのファイルがあれば、これからシステムにインストールするパッケージにおいて利用していくことができます。 パッケージはバイナリ形式であっても、ビルドするものであってもかまいません。
1 つめのファイルは Linux Standards Base (LSB) の観点で、あなたのシステムがどのような状況にあるかを示すものです。 これを作成するために以下のコマンドを実行します。
cat > /etc/lsb-release << "EOF" DISTRIB_ID="Linux From Scratch" DISTRIB_RELEASE="11.2-systemd" DISTRIB_CODENAME="<your name here>" DISTRIB_DESCRIPTION="Linux From Scratch" EOF
2 つめのファイルは、だいたい同じ情報を含むものですが、systemd やグラフィカルデスクトップ環境がこれを利用します。 これを作成するために以下のコマンドを実行します。
cat > /etc/os-release << "EOF" NAME="Linux From Scratch" VERSION="11.2-systemd" ID=lfs PRETTY_NAME="Linux From Scratch 11.2-systemd" VERSION_CODENAME="<your name here>" EOF
'DISTRIB_CODENAME' と 'VERSION_CODENAME' の両項目に対しては、あなたのシステムを特定できるように適切に設定してください。
これにより本書の作業は終了です。 LFS ユーザー登録を行ってカウンターを取得しますか? 以下のページ https://www.linuxfromscratch.org/cgi-bin/lfscounter.php にて、初めて構築した LFS のバージョンと氏名を登録して下さい。
それではシステムの再起動を行ないましょう。
ソフトウェアのインストールがすべて完了しました。 ここでコンピューターを再起動しますが、いくつか注意しておいて下さい。 本書を通じて構築したシステムは最小限のものです。 これ以降にさまざまなことを繰り広げていくには、機能が不足しているはずです。 もうしばらくは今までと同じように chroot 環境を利用して BLFS ブックからいくつかのパッケージをインストールしていきましょう。 その後のリブートにより新しい LFS システムを起動すれば、より一層、満足できる環境を得ることになるはずです。 以下はその際の構築例です。
Lynx のようなテキストブラウザーをインストールしておけば、仮想端末からでも BLFS ブックを簡単に参照しながらパッケージビルド作業を進めることができます。
make-ca パッケージをインストールしていると、ローカルにおいて信頼されるアンカー証明書を構築できます。 そうすればリモートサーバー(たとえば HTTPS を用いたウェブサイト)が提供する SSL 証明書をシステムが検証できます。
GPM パッケージをインストールすれば、仮想端末内にてコピーペースト操作を行うことができます。
sudo をインストールすれば、root
ユーザー以外であっても、パッケージビルドとインストールを容易に行うことができます。
利用しやすい GUI 操作を通じてリモート接続を行いたい場合は openssh をインストールします。
インターネット経由により簡単にファイル取得を行うために wget をインストールします。
ワイアレスのネットワークアクセスポイントに接続する場合は、wpa_supplicant をインストールしてください。
利用するハードウェア用のカーネルドライバーが、それを適切に動作させるために何か別のファームウェアを利用している場合は、firmwares をインストールしてください。
最後に、以下に示す種々の設定ファイルが適切であるかどうかを確認します。
/etc/bashrc
/etc/dircolors
/etc/fstab
/etc/hosts
/etc/inputrc
/etc/profile
/etc/resolv.conf
/etc/vimrc
/root/.bash_profile
/root/.bashrc
さあよろしいですか。 新しくインストールした LFS システムの再起動を行いましょう。 まずは chroot 環境から抜けます。
logout
仮想ファイルシステムをアンマウントします。
umount -v $LFS/dev/pts umount -v $LFS/dev umount -v $LFS/run umount -v $LFS/proc umount -v $LFS/sys
複数のパーティションを生成していた場合は、メインのパーティションをアンマウントする前に、個々のパーティションをアンマウントします。
umount -v $LFS/usr umount -v $LFS/home umount -v $LFS
LFS ファイルシステムそのものをアンマウントします。
umount -v $LFS
以下のようにしてシステムを再起動します。
shutdown -r now
これまでの作業にて GRUB ブートローダーが設定されているはずです。 そのメニューには LFS 11.2-systemd を起動するためのメニュー項目があるはずです。
再起動が無事行われ LFS システムを使うことができます。 必要に応じてさらなるソフトウェアをインストールしていってください。
本書をお読み頂き、ありがとうございます。 本書が皆さんにとって有用なものとなり、システムの構築方法について十分に学んで頂けたものと思います。
LFS システムをインストールしたら「次は何を?」とお考えになるかもしれません。 その質問に答えるために以下に各種の情報をまとめます。
保守
あらゆるソフトウェアにおいて、バグやセキュリティの情報は日々報告されています。 LFS システムはソースコードからコンパイルしていますので、そのような報告を見逃さずにおくことは皆さんの仕事となります。 そのような報告をオンラインで提供する情報の場がありますので、いくつかを以下に示しましょう。
CERT (Computer Emergency Response Team)
CERT にはメーリングリストがあり、数々のオペレーティングシステムやアプリケーションにおけるセキュリティ警告を公開しています。 購読に関する情報は http://www.us-cert.gov/cas/signup.html を参照してください。
バグトラック (Bugtraq)
バグトラックは、完全公開のコンピューターセキュリティに関するメーリングリストです。 これは新たに発見されたセキュリティに関する問題を公開しています。 また時には、その問題を解消するフィックス情報も提供してくれます。 購読に関する情報は http://www.securityfocus.com/archive を参照してください。
Beyond Linux From Scratch
Beyond Linux From Scratch ブックは、LFS ブックが取り扱うソフトウェアの範囲を超えて、数多くのソフトウェアをインストールする手順を示しています。 BLFS プロジェクトは以下にあります。 https://www.linuxfromscratch.org/blfs/view/stable-systemd/
LFS ヒント (LFS Hints)
LFS ヒントは有用なドキュメントを集めたものです。 LFS コミュニティのボランティアによって投稿されたものです。 それらのヒントは https://www.linuxfromscratch.org/hints/downloads/files/ にて参照することができます。
メーリングリスト
皆さんにも参加して頂ける LFS メーリングリストがあります。 何かの助けが必要になったり、最新の開発を行いたかったり、あるいはプロジェクトに貢献したいといった場合に、参加して頂くことができます。 詳しくは 第 1 章 - メーリングリストを参照してください。
Linux ドキュメントプロジェクト (The Linux Documentation Project; TLDP)
Linux ドキュメントプロジェクトの目指すことは Linux のドキュメントに関わる問題を共同で取り組むことです。 TLDP ではハウツー (HOWTO)、ガイド、man ページを数多く提供しています。 以下のサイトにあります。 http://www.tldp.org/
本節における日本語訳は、訳語が一般的に普及していると思われるものは、その訳語とカッコ書き内に原語を示します。 逆に訳語に適当なものがないと思われるものは、無理に訳出せず原語だけを示すことにします。 この判断はあくまで訳者によるものであるため、不適切・不十分な個所についてはご指摘ください。
ABI |
アプリケーション バイナリ インターフェース (Application Binary Interface) |
ALFS |
Automated Linux From Scratch |
API |
アプリケーション プログラミング インターフェース (Application Programming Interface) |
ASCII |
American Standard Code for Information Interchange |
BIOS |
ベーシック インプット/アウトプット システム; バイオス (Basic Input/Output System) |
BLFS |
Beyond Linux From Scratch |
BSD |
Berkeley Software Distribution |
chroot |
ルートのチェンジ (change root) |
CMOS |
シーモス (Complementary Metal Oxide Semiconductor) |
COS |
Class Of Service |
CPU |
中央演算処理装置 (Central Processing Unit) |
CRC |
巡回冗長検査 (Cyclic Redundancy Check) |
CVS |
Concurrent Versions System |
DHCP |
ダイナミック ホスト コンフィギュレーション プロトコル (Dynamic Host Configuration Protocol) |
DNS |
ドメインネームサービス (Domain Name Service) |
EGA |
Enhanced Graphics Adapter |
ELF |
Executable and Linkable Format |
EOF |
ファイルの終端 (End of File) |
EQN |
式 (equation) |
ext2 |
second extended file system |
ext3 |
third extended file system |
ext4 |
fourth extended file system |
FAQ |
よく尋ねられる質問 (Frequently Asked Questions) |
FHS |
ファイルシステム階層標準 (Filesystem Hierarchy Standard) |
FIFO |
ファーストイン、ファーストアウト (First-In, First Out) |
FQDN |
完全修飾ドメイン名 (Fully Qualified Domain Name) |
FTP |
ファイル転送プロトコル (File Transfer Protocol) |
GB |
ギガバイト (gigabytes) |
GCC |
GNU コンパイラー コレクション (GNU Compiler Collection) |
GID |
グループ識別子 (Group Identifier) |
GMT |
グリニッジ標準時 (Greenwich Mean Time) |
HTML |
ハイパーテキスト マークアップ 言語 (Hypertext Markup Language) |
IDE |
Integrated Drive Electronics |
IEEE |
Institute of Electrical and Electronic Engineers |
IO |
入出力 (Input/Output) |
IP |
インターネット プロトコル (Internet Protocol) |
IPC |
プロセス間通信 (Inter-Process Communication) |
IRC |
インターネット リレー チャット (Internet Relay Chat) |
ISO |
国際標準化機構 (International Organization for Standardization) |
ISP |
インターネット サービス プロバイダー (Internet Service Provider) |
KB |
キロバイト (kilobytes) |
LED |
発光ダイオード (Light Emitting Diode) |
LFS |
Linux From Scratch |
LSB |
Linux Standard Base |
MB |
メガバイト (megabytes) |
MBR |
マスター ブート レコード (Master Boot Record) |
MD5 |
Message Digest 5 |
NIC |
ネットワーク インターフェース カード (Network Interface Card) |
NLS |
Native Language Support |
NNTP |
Network News Transport Protocol |
NPTL |
Native POSIX Threading Library |
OSS |
Open Sound System |
PCH |
プリコンパイル済みヘッダー (Pre-Compiled Headers) |
PCRE |
Perl Compatible Regular Expression |
PID |
プロセス識別子 (Process Identifier) |
PTY |
仮想端末 (pseudo terminal) |
QOS |
クオリティ オブ サービス (Quality Of Service) |
RAM |
ランダム アクセス メモリ (Random Access Memory) |
RPC |
リモート プロシージャ コール (Remote Procedure Call) |
RTC |
リアルタイムクロック (Real Time Clock) |
SBU |
標準ビルド時間 (Standard Build Unit) |
SCO |
サンタ クルズ オペレーション社 (The Santa Cruz Operation) |
SHA1 |
Secure-Hash Algorithm 1 |
TLDP |
The Linux Documentation Project |
TFTP |
Trivial File Transfer Protocol |
TLS |
スレッド ローカル ストレージ (Thread-Local Storage) |
UID |
ユーザー識別子 (User Identifier) |
umask |
user file-creation mask |
USB |
ユニバーサル シリアル バス (Universal Serial Bus) |
UTC |
協定世界時 (Coordinated Universal Time) |
UUID |
汎用一意識別子 (Universally Unique Identifier) |
VC |
仮想コンソール (Virtual Console) |
VGA |
ビデオ グラフィックス アレー (Video Graphics Array) |
VT |
仮想端末 (Virtual Terminal) |
Linux From Scratch プロジェクトへ貢献して下さった以下の方々および組織団体に感謝致します。
Gerard Beekmans <gerard AT linuxfromscratch D0T org> – LFS 構築者
Bruce Dubbs <bdubbs AT linuxfromscratch D0T org> – LFS 編集管理者
Jim Gifford <jim AT linuxfromscratch D0T org> – CLFS プロジェクト共同リーダー
Pierre Labastie <pierre AT linuxfromscratch D0T org> – BLFS 編集者、ALFS リーダー
DJ Lucas <dj AT linuxfromscratch D0T org> – LFS、BLFS 編集者
Ken Moffat <ken AT linuxfromscratch D0T org> – BLFS 編集者
この他に数多くの方々にも協力頂きました。 皆さまには LFS や BLFS などのメーリングリストにて、提案、ブック内容のテスト、バグ報告、作業指示、パッケージインストールの経験談などを通じて、本ブック製作にご協力頂きました。
Manuel Canales Esparcia <macana AT macana-es D0T com> – スペインの LFS 翻訳プロジェクト
Johan Lenglet <johan AT linuxfromscratch D0T org> – フランスの LFS 翻訳プロジェクト; 2008年まで
Jean-Philippe Mengual <jmengual AT linuxfromscratch D0T org> – フランスの LFS 翻訳プロジェクト; 2008年~2016年まで
Julien Lepiller <jlepiller AT linuxfromscratch D0T org> – フランスの LFS 翻訳プロジェクト; 2017年から現在まで
Anderson Lizardo <lizardo AT linuxfromscratch D0T org> – ポルトガルの LFS 翻訳プロジェクト
Thomas Reitelbach <tr AT erdfunkstelle D0T de> – ドイツの LFS 翻訳プロジェクト
Scott Kveton <scott AT osuosl D0T org> – lfs.oregonstate.edu ミラー
William Astle <lost AT l-w D0T net> – ca.linuxfromscratch.org ミラー
Eujon Sellers <jpolen@rackspace.com> – lfs.introspeed.com ミラー
Justin Knierim <tim@idge.net> – lfs-matrix.net ミラー
Manuel Canales Esparcia <manuel AT linuxfromscratch D0T org> – lfsmirror.lfs-es.info ミラー
Luis Falcon <Luis Falcon> – torredehanoi.org ミラー
Guido Passet <guido AT primerelay D0T net> – nl.linuxfromscratch.org ミラー
Bastiaan Jacques <baafie AT planet D0T nl> – lfs.pagefault.net ミラー
Sven Cranshoff <sven D0T cranshoff AT lineo D0T be> – lfs.lineo.be ミラー
Scarlet Belgium – lfs.scarlet.be ミラー
Sebastian Faulborn <info AT aliensoft D0T org> – lfs.aliensoft.org ミラー
Stuart Fox <stuart AT dontuse D0T ms> – lfs.dontuse.ms ミラー
Ralf Uhlemann <admin AT realhost D0T de> – lfs.oss-mirror.org ミラー
Antonin Sprinzl <Antonin D0T Sprinzl AT tuwien D0T ac D0T at> – at.linuxfromscratch.org ミラー
Fredrik Danerklint <fredan-lfs AT fredan D0T org> – se.linuxfromscratch.org ミラー
Franck <franck AT linuxpourtous D0T com> – lfs.linuxpourtous.com ミラー
Philippe Baque <baque AT cict D0T fr> – lfs.cict.fr ミラー
Vitaly Chekasin <gyouja AT pilgrims D0T ru> – lfs.pilgrims.ru ミラー
Benjamin Heil <kontakt AT wankoo D0T org> – lfs.wankoo.org ミラー
Anton Maisak <info AT linuxfromscratch D0T org D0T ru> – linuxfromscratch.org.ru ミラー
Satit Phermsawang <satit AT wbac D0T ac D0T th> – lfs.phayoune.org ミラー
Shizunet Co.,Ltd. <info AT shizu-net D0T jp> – lfs.mirror.shizu-net.jp ミラー
Init World <http://www.initworld.com/> – lfs.initworld.com ミラー
Jason Andrade <jason AT dstc D0T edu D0T au> – au.linuxfromscratch.org ミラー
Christine Barczak <theladyskye AT linuxfromscratch D0T org> – LFS ブック編集者
Archaic <archaic@linuxfromscratch.org> – LFS テクニカルライター/編集者、HLFS プロジェクトリーダー、BLFS 編集者、ヒントプロジェクトとパッチプロジェクトの管理者
Matthew Burgess <matthew AT linuxfromscratch D0T org> – LFS プロジェクトリーダー、LFS テクニカルライター/編集者
Nathan Coulson <nathan AT linuxfromscratch D0T org> – LFS-ブートスクリプトの管理者
Timothy Bauscher
Robert Briggs
Ian Chilton
Jeroen Coumans <jeroen AT linuxfromscratch D0T org> – ウェブサイト開発者、FAQ 管理者
Manuel Canales Esparcia <manuel AT linuxfromscratch D0T org> – LFS/BLFS/HLFS の XML と XSL の管理者
Alex Groenewoud – LFS テクニカルライター
Marc Heerdink
Jeremy Huntwork <jhuntwork AT linuxfromscratch D0T org> – LFS テクニカルライター、LFS LiveCD 管理者
Bryan Kadzban <bryan AT linuxfromscratch D0T org> – LFS テクニカルライター
Mark Hymers
Seth W. Klein – FAQ 管理者
Nicholas Leippe <nicholas AT linuxfromscratch D0T org> – Wiki 管理者
Anderson Lizardo <lizardo AT linuxfromscratch D0T org> – ウェブサイトのバックエンドスクリプトの管理者
Randy McMurchy <randy AT linuxfromscratch D0T org> – BLFS プロジェクトリーダー、LFS 編集者
Dan Nicholson <dnicholson AT linuxfromscratch D0T org> – LFS/BLFS 編集者
Alexander E. Patrakov <alexander AT linuxfromscratch D0T org> – LFS テクニカルライター、LFS 国際化に関する編集者、LFS Live CD 管理者
Simon Perreault
Scot Mc Pherson <scot AT linuxfromscratch D0T org> – LFS NNTP ゲートウェイ管理者
Douglas R. Reno <renodr AT linuxfromscratch D0T org> – Systemd 編集者
Ryan Oliver <ryan AT linuxfromscratch D0T org> – CLFS プロジェクト共同リーダー
Greg Schafer <gschafer AT zip D0T com D0T au> – LFS テクニカルライター、次世代 64 ビット機での構築手法の開発者
Jesse Tie-Ten-Quee – LFS テクニカルライター
James Robertson <jwrober AT linuxfromscratch D0T org> – Bugzilla 管理者
Tushar Teredesai <tushar AT linuxfromscratch D0T org> – BLFS ブック編集者、ヒントプロジェクト・パッチプロジェクトのリーダー
Jeremy Utley <jeremy AT linuxfromscratch D0T org> – LFS テクニカルライター、Bugzilla 管理者、LFS-ブートスクリプト管理者
Zack Winkles <zwinkles AT gmail D0T com> – LFS テクニカルライター
LFS にて構築するパッケージはすべて、他のいくつかのパッケージに依存していて、それらがあって初めて適切にインストールができます。 パッケージの中には互いに依存し合っているものもあります。 つまり一つめのパッケージが二つめのパッケージに依存しており、二つめが実は一つめのパッケージにも依存しているような例です。 こういった依存関係があることから LFS においてパッケージを構築する順番は非常に重要なものとなります。 本節は LFS にて構築する各パッケージの依存関係を示すものです。
ビルドするパッケージの個々には、3 種類あるいは、最大で 5 種類の依存関係を示しています。 1 つめは、対象パッケージをコンパイルしてビルドするために必要となるパッケージです。 2 つめは、対象パッケージのプログラムやライブラリが、実行時にその利用を必要とするパッケージです。 3 つめは、1 つめのものに加えて、テストスイートを実行するために必要となるパッケージです。 4 つめ以降は、対象パッケージをビルドし、最終的にインストールするために必要となるパッケージです。 たいていの場合、それらのパッケージに含まれているスクリプトが、実行モジュールへのパスを固定的に取り扱っています。 所定の順番どおりにパッケージのビルドを行わないと、最終的にインストールされるシステムにおいて、スクリプトの中に /tools/bin/[実行モジュール] といったパスが含まれてしまうことになりかねません。 これは明らかに不適切なことです。
依存関係として4つめに示すのは任意のパッケージであり LFS では説明していないものです。 しかし皆さんにとっては有用なパッケージであるはずです。 それらのパッケージは、さらに別のパッケージを必要としていたり、互いに依存し合っていることがあります。 そういった依存関係があるため、それらをインストールする場合には、LFS をすべて仕上げた後に再度 LFS 内のパッケージを再構築する方法をお勧めします。 再インストールに関しては、たいていは BLFS にて説明しています。
本ブックはクリエイティブコモンズ (Creative Commons) の 表示-非営利-継承 (Attribution-NonCommercial-ShareAlike) 2.0 ライセンスに従います。
本書のインストール手順のコマンドを抜き出したものは MIT ライセンスに従ってください。
以下は日本語へ訳出することなく、原文のライセンス条項をそのまま示します。
Creative Commons Legal Code
Attribution-NonCommercial-ShareAlike 2.0
CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE LEGAL SERVICES. DISTRIBUTION OF THIS LICENSE DOES NOT CREATE AN ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES REGARDING THE INFORMATION PROVIDED, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM ITS USE.
License
THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.
BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.
Definitions
"Collective Work" means a work, such as a periodical issue, anthology or encyclopedia, in which the Work in its entirety in unmodified form, along with a number of other contributions, constituting separate and independent works in themselves, are assembled into a collective whole. A work that constitutes a Collective Work will not be considered a Derivative Work (as defined below) for the purposes of this License.
"Derivative Work" means a work based upon the Work or upon the Work and other pre-existing works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which the Work may be recast, transformed, or adapted, except that a work that constitutes a Collective Work will not be considered a Derivative Work for the purpose of this License. For the avoidance of doubt, where the Work is a musical composition or sound recording, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered a Derivative Work for the purpose of this License.
"Licensor" means the individual or entity that offers the Work under the terms of this License.
"Original Author" means the individual or entity who created the Work.
"Work" means the copyrightable work of authorship offered under the terms of this License.
"You" means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation.
"License Elements" means the following high-level license attributes as selected by Licensor and indicated in the title of this License: Attribution, Noncommercial, ShareAlike.
Fair Use Rights. Nothing in this license is intended to reduce, limit, or restrict any rights arising from fair use, first sale or other limitations on the exclusive rights of the copyright owner under copyright law or other applicable laws.
License Grant. Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below:
to reproduce the Work, to incorporate the Work into one or more Collective Works, and to reproduce the Work as incorporated in the Collective Works;
to create and reproduce Derivative Works;
to distribute copies or phonorecords of, display publicly, perform publicly, and perform publicly by means of a digital audio transmission the Work including as incorporated in Collective Works;
to distribute copies or phonorecords of, display publicly, perform publicly, and perform publicly by means of a digital audio transmission Derivative Works;
The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. All rights not expressly granted by Licensor are hereby reserved, including but not limited to the rights set forth in Sections 4(e) and 4(f).
Restrictions.The license granted in Section 3 above is expressly made subject to and limited by the following restrictions:
You may distribute, publicly display, publicly perform, or publicly digitally perform the Work only under the terms of this License, and You must include a copy of, or the Uniform Resource Identifier for, this License with every copy or phonorecord of the Work You distribute, publicly display, publicly perform, or publicly digitally perform. You may not offer or impose any terms on the Work that alter or restrict the terms of this License or the recipients' exercise of the rights granted hereunder. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties. You may not distribute, publicly display, publicly perform, or publicly digitally perform the Work with any technological measures that control access or use of the Work in a manner inconsistent with the terms of this License Agreement. The above applies to the Work as incorporated in a Collective Work, but this does not require the Collective Work apart from the Work itself to be made subject to the terms of this License. If You create a Collective Work, upon notice from any Licensor You must, to the extent practicable, remove from the Collective Work any reference to such Licensor or the Original Author, as requested. If You create a Derivative Work, upon notice from any Licensor You must, to the extent practicable, remove from the Derivative Work any reference to such Licensor or the Original Author, as requested.
You may distribute, publicly display, publicly perform, or publicly digitally perform a Derivative Work only under the terms of this License, a later version of this License with the same License Elements as this License, or a Creative Commons iCommons license that contains the same License Elements as this License (e.g. Attribution-NonCommercial-ShareAlike 2.0 Japan). You must include a copy of, or the Uniform Resource Identifier for, this License or other license specified in the previous sentence with every copy or phonorecord of each Derivative Work You distribute, publicly display, publicly perform, or publicly digitally perform. You may not offer or impose any terms on the Derivative Works that alter or restrict the terms of this License or the recipients' exercise of the rights granted hereunder, and You must keep intact all notices that refer to this License and to the disclaimer of warranties. You may not distribute, publicly display, publicly perform, or publicly digitally perform the Derivative Work with any technological measures that control access or use of the Work in a manner inconsistent with the terms of this License Agreement. The above applies to the Derivative Work as incorporated in a Collective Work, but this does not require the Collective Work apart from the Derivative Work itself to be made subject to the terms of this License.
You may not exercise any of the rights granted to You in Section 3 above in any manner that is primarily intended for or directed toward commercial advantage or private monetary compensation. The exchange of the Work for other copyrighted works by means of digital file-sharing or otherwise shall not be considered to be intended for or directed toward commercial advantage or private monetary compensation, provided there is no payment of any monetary compensation in connection with the exchange of copyrighted works.
If you distribute, publicly display, publicly perform, or publicly digitally perform the Work or any Derivative Works or Collective Works, You must keep intact all copyright notices for the Work and give the Original Author credit reasonable to the medium or means You are utilizing by conveying the name (or pseudonym if applicable) of the Original Author if supplied; the title of the Work if supplied; to the extent reasonably practicable, the Uniform Resource Identifier, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and in the case of a Derivative Work, a credit identifying the use of the Work in the Derivative Work (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). Such credit may be implemented in any reasonable manner; provided, however, that in the case of a Derivative Work or Collective Work, at a minimum such credit will appear where any other comparable authorship credit appears and in a manner at least as prominent as such other comparable authorship credit.
For the avoidance of doubt, where the Work is a musical composition:
Performance Royalties Under Blanket Licenses. Licensor reserves the exclusive right to collect, whether individually or via a performance rights society (e.g. ASCAP, BMI, SESAC), royalties for the public performance or public digital performance (e.g. webcast) of the Work if that performance is primarily intended for or directed toward commercial advantage or private monetary compensation.
Mechanical Rights and Statutory Royalties. Licensor reserves the exclusive right to collect, whether individually or via a music rights agency or designated agent (e.g. Harry Fox Agency), royalties for any phonorecord You create from the Work ("cover version") and distribute, subject to the compulsory license created by 17 USC Section 115 of the US Copyright Act (or the equivalent in other jurisdictions), if Your distribution of such cover version is primarily intended for or directed toward commercial advantage or private monetary compensation. 6. Webcasting Rights and Statutory Royalties. For the avoidance of doubt, where the Work is a sound recording, Licensor reserves the exclusive right to collect, whether individually or via a performance-rights society (e.g. SoundExchange), royalties for the public digital performance (e.g. webcast) of the Work, subject to the compulsory license created by 17 USC Section 114 of the US Copyright Act (or the equivalent in other jurisdictions), if Your public digital performance is primarily intended for or directed toward commercial advantage or private monetary compensation.
Webcasting Rights and Statutory Royalties. For the avoidance of doubt, where the Work is a sound recording, Licensor reserves the exclusive right to collect, whether individually or via a performance-rights society (e.g. SoundExchange), royalties for the public digital performance (e.g. webcast) of the Work, subject to the compulsory license created by 17 USC Section 114 of the US Copyright Act (or the equivalent in other jurisdictions), if Your public digital performance is primarily intended for or directed toward commercial advantage or private monetary compensation.
Representations, Warranties and Disclaimer
UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.
Limitation on Liability. EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Termination
This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Derivative Works or Collective Works from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License.
Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above.
Miscellaneous
Each time You distribute or publicly digitally perform the Work or a Collective Work, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License.
Each time You distribute or publicly digitally perform a Derivative Work, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License.
If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.
No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent.
This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.
Creative Commons is not a party to this License, and makes no warranty whatsoever in connection with the Work. Creative Commons will not be liable to You or any party on any legal theory for any damages whatsoever, including without limitation any general, special, incidental or consequential damages arising in connection to this license. Notwithstanding the foregoing two (2) sentences, if Creative Commons has expressly identified itself as the Licensor hereunder, it shall have all rights and obligations of Licensor.
Except for the limited purpose of indicating to the public that the Work is licensed under the CCPL, neither party will use the trademark "Creative Commons" or any related trademark or logo of Creative Commons without the prior written consent of Creative Commons. Any permitted use will be in compliance with Creative Commons' then-current trademark usage guidelines, as may be published on its website or otherwise made available upon request from time to time.
Creative Commons may be contacted at http://creativecommons.org/.
以下は日本語へ訳出することなく、原文のライセンス条項をそのまま示します。
Copyright © 1999-2022 Gerard Beekmans
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.