まえがき
そこで、 前の記事で、 LFSの収集を開始しました。これは、ツールのさらなる組み立てに必要なすべてを備えた一時的なシステムを組み立てたという事実に焦点を当てています。
次に、メインシステムを構築し、作業に必要な設定を行います。 この記事ではLFSシリーズを続けますが、これ以上苦労することなく、ビジネスに取り掛かりましょう。
ただし、先に進む前に、本の著者によって提案された古典的なスキームから少し離れて、これを行いましょう
$ su - lfs $ wget http://roy.marples.name/downloads/dhcpcd/dhcpcd-6.7.1.tar.bz2 --directory-prefix=$LFS/sources $ wget http://www.linuxfromscratch.org/blfs/downloads/7.7/blfs-bootscripts-20150304.tar.bz2 --directory-prefix=$LFS/sources $ logout
実際には、基本システムのアセンブリに関する標準文書には、DNSプロバイダーからIPアドレスを受け取る場合、または動的IPがホームルーターを提供する場合のネットワークセットアッププロセスが記載されていません。 または、NAT経由でネットワークにアクセスできるVMの下で構築している場合。
したがって、すべてを収集した後、DHCPクライアントを追加インストールして構成します。これにより、再起動後すぐに新しいシステムがIPを取得し、ネットワークにアクセスできるようになります。 このステップはすでにBLFSブックに適用されます。
1.偉大で恐ろしいChroot
まず、rootを$ LFS / toolsディレクトリの所有者にします
$ su - root # export LFS=/mnt/lfs # chown -R root:root $LFS/tools
それ以前は、lfsユーザーに属していましたが、このユーザーはホストシステム上にあり、そこにはありません(まだユーザーはいません!)収集しているシステム上にあります。 以降のすべてのアクションは、システムが進むセクションのルートから実行されます。 この点で、次の問題を解決する必要があります
- 問題#1 (メイン):使用するすべてのパスは、実際のシステムのルートから開始する必要があります。 これは、環境全体およびシステムのカーネルの正常な動作に不可欠です。
- 問題#2 (付随):組み立てられたシステムとホストシステムのバイナリファイルのインストールパスが一致する(またはほぼ一致する)事実を考慮して、ホストと組み立てられたシステムのシステムディレクトリを相互に「フェンス」する必要があります。
両方の問題は、外出先でシステムのルートディレクトリを変更できるchrootコマンドによって解決されます。 $ LFSパーティションのchroot実行フィールドは、LFSディレクトリへのすべてのパスが「/」で始まります。つまり、構築中のシステムのルートに作業の外観を作成します。 $ LFSより上にあるディレクトリ(つまり、/ mnt / lfsディレクトリ)は完全に切断され、アクセスできなくなります。 これはすばらしいことです。ルートとして実行するすべてのアクションは、ホストシステムに影響しません。 ただし、VFS-ホストマシンの仮想ファイルシステムにアクセスする必要があります。これは、/ dev、/ proc、/ sys、および/ runの各ディレクトリで構成されます。 UNIXの基本概念の1つである「すべてがファイルです」を覚えています。 機器とシステムのリソースにアクセスする必要があり、それはVFSオブジェクトを使用して行われます。
最初に必要なディレクトリを対応するLFSディレクトリにマウントすると、chrootからホストシステムディレクトリへのアクセスが可能になります。 これを行うには、次の操作を実行します。 VFSマウントポイントを作成する
# mkdir -pv $LFS/{dev,proc,sys,run}
キャラクターデバイス/ dev / consoleおよび/ dev / nullを作成します
# mknod -m 600 $LFS/dev/console c 5 1 # mknod -m 666 $LFS/dev/null c 1 3
-mスイッチは、デバイスファイルへのアクセス権を定義します。 c-デバイスがシンボリックであり、後続の数字がデバイスのメジャー番号とマイナー番号であることを示します。 最初はキャラクターデバイスのタイプを特徴づけ、2番目はシステム内のデバイスの番号です。
/ dev / consoleはシステムに端末を提供します。/ dev / nullは空のファイルからデータを取得したり、出力をどこにもリダイレクトしないために最もよく使用されます。
ここで、仮想ファイルシステムを特別な方法でマウントします。 このようなマウントはしばしば「バインディング」と呼ばれます-実行されると、マウントされたディレクトリの内容はマウントポイントとして指定されたディレクトリにマップされます
# mount -v --bind /dev $LFS/dev
これで、一時システムがデバイスファイルにアクセスできるようになります。 残りのVFSホストをマウントします
# mount -vt devpts devpts $LFS/dev/pts -o gid=5,mode=620 # mount -vt proc proc $LFS/proc # mount -vt sysfs sysfs $LFS/sys # mount -vt tmpfs tmpfs $LFS/run
/ dev / ptsは、擬似端末へのアクセスを提供するファイルシステムです。 アクセス権を持つttyグループの識別子gid = 5でマウントされます620(-rw- -r- ---)。
/ procは、システムで実行されているプロセスに関する情報を含む仮想ファイルシステムです。
/ sys-システムに存在するデバイスとドライバーに関する情報をユーザー空間に追加する仮想ファイルシステム
/ runは、システムブートの初期段階で一時ファイルを作成するように設計された仮想ファイルシステムです。 以前は、同様のファイルが/ devに作成されていましたが、Lennard Potteringの主導で、systemdのプロモーションに関連して、この目的のために追加のディレクトリが追加されました。
さらに、/ devの一部のホストシステムでは、/ run / shmへのシンボリックリンクが存在する場合があります-共有メモリにアクセスするための一時ファイルです。 ホスト上の可用性を確認し、必要に応じて一時システムで作成します
$ if [ -h $LFS/dev/shm ]; then > mkdir -pv $LFS/$(readlink $LFS/dev/shm) > fi
「悪魔」の後、次の図に概略的に示す構造が得られます。
ホストシステムに関連するLFSディレクトリツリー

実際には一時システムにログインしています
# chroot "$LFS" /tools/bin/env -i \ > HOME=/root \ > TERM="$TERM" \ > PS1='\u:\w\$ ' \ > PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \ > /tools/bin/bash --login +h
このコマンドは、システムのルートディレクトリを$ LFSに変更し、2つのコマンドを実行します-/ tools / bin / env-新しい「クリーンな」ユーザー環境を作成し、いくつかの変数を割り当てます。HOME-ホームディレクトリの位置。 TERM-端末タイプ。 PS1-コマンドラインプロンプト形式。 PATH-実行可能ファイルへのパスのリスト。 / tools / bin / bash --login + h-シェルの新しいインスタンスを起動します。起動は、実行可能ファイルへのパスのハッシュを無効にして、別のユーザーセッションへの入り口として実行されます。 前のステップで作成したプログラム(envおよびbash)を使用することに注意してください。
コマンドを実行すると、次の結果が得られます
I have no name!:/# ls dev proc run sources sys tools
システムのルートが正常に変更され、コマンドプロンプトに「名前がありません!」という警告が表示されます。これは、システムに/ etc / passwdファイルがないために発生します。 迷惑をかけないでください。すぐにファイルを作成します。
注 :システムの組み立てには時間がかかるため、VFSとchrootマウントコマンドを組み合わせてスクリプトを作成し、コンピューターの電源を切った後に構築するシステムへの入力を簡素化できます。
2.必要なディレクトリとファイルを作成する
次に、システムのディレクトリツリーを作成する必要があります
# mkdir -pv /{bin,boot,etc/{opt,sysconfig},home,lib/firmware,mnt,opt} # mkdir -pv /{media/{floppy,cdrom},sbin,srv,var} # install -dv -m 0750 /root # install -dv -m 1777 /tmp /var/tmp # mkdir -pv /usr/{,local/}{bin,include,lib,sbin,src} # mkdir -pv /usr/{,local/}share/{color,dict,doc,info,locale,man} # mkdir -v /usr/{,local/}share/{misc,terminfo,zoneinfo} # mkdir -v /usr/libexec # mkdir -pv /usr/{,local/}share/man/man{1..8} # case $(uname -m) in > x86_64) ln -sv lib /lib64 > ln -sv lib /usr/lib64 > ln -sv lib /usr/local/lib64 ;; > esac # mkdir -v /var/{log,mail,spool} # ln -sv /run /var/run # ln -sv /run/lock /var/lock # mkdir -pv /var/{opt,cache,lib/{color,misc,locate},local}
mkdirコマンドによって作成されたディレクトリは、デフォルトで755(drwx rx rx)許可になります。 この場合、installコマンドを使用して、特定のアクセス属性を持つディレクトリを作成します。0750(drwx rx ---)for / root-スーパーユーザーのルートディレクトリ。 / tmpおよび/ var / tmpの1777(drwx rwx rwx)-一時ファイルのディレクトリ。例外なくシステムのすべてのユーザーがアクセスできる必要があります。 ただし、一時ディレクトリに含まれる別のユーザーのファイルの移動を禁止する必要があります。 これを行うために、いわゆるスティッキービットがコックされ、一時ディレクトリ内のファイルの削除は所有者のみに許可されることを示します。
64ビットシステムを構築している場合は、システムライブラリを含む/ libディレクトリへのシンボリックリンクを作成する必要があります。 さらに、一部のプログラムは、システムの必要なコンポーネントへのハードコーディングされたパスを使用します。 一時システムで作業している間、これらのパスは異なるため(たとえば、これまでのすべての実行可能ファイルは/ tools / binディレクトリにあります)、この矛盾を修正するためにシンボリックリンクを作成する必要があります
# ln -sv /tools/bin/{bash,cat,echo,pwd,stty} /bin # ln -sv /tools/bin/perl /usr/bin # ln -sv /tools/lib/libgcc_s.so{,.1} /usr/lib # ln -sv /tools/lib/libstdc++.so{,.6} /usr/lib # sed 's/tools/usr/' /tools/lib/libstdc++.la > /usr/lib/libstdc++.la # ln -sv bash /bin/sh
従来、Linuxでは、マウントされたファイルシステムのリストは/ etc / mtabファイルにありました。 ただし、最新のカーネルはこれに/ proc仮想ファイルシステムを使用します。 シンボリックリンクを作成する
# ln -sv /proc/self/mounts /etc/mtab
/ etc / mtabを使用し続けるプログラムの場合。
次に、システムに登録されているユーザーのリストを含む/ etc / passwdファイルを作成する必要があります。
# cat > /etc/passwd << "EOF" > root:x:0:0:root:/root:/bin/bash > bin:x:1:1:bin:/dev/null:/bin/false > daemon:x:6:6:Daemon User:/dev/null:/bin/false > messagebus:x:18:18:D-Bus Message Daemon User:/var/run/dbus:/bin/false > nobody:x:99:99:Unprivileged User:/dev/null:/bin/false > EOF
一時的なシステムにはテキストエディターがないため、標準入力のファイルへのリダイレクトを使用します。 このテキストファイルの形式は次のとおりです。各行には、ユーザーに関する情報がフォームに含まれています
<login>:<password>:<UID>:<GID>:<GECOS>:<home>:<shell>
- ログイン-システムのユーザー名
- password-以前にここに保存されていたパスワードハッシュですが、現在は別のファイル/ etc / shadowに移動されており、通常のユーザーが読み取ることはできません。 代わりに、プレースホルダー「x」が配置されるようになりました
- UID-ユーザー識別子-0〜2 32-1の数字。実際、このファイルの主な目的は、ログインとユーザー識別子を比較することです。
- GID-ユーザーが含まれるデフォルトグループの識別子
- GECOS-ユーザーに関する追加情報を保存する情報フィールド。 明確な構文はなく、実際、このアカウントに関するコメントが含まれている場合があります。
- home-ユーザーのホームディレクトリへの絶対パス
- shell-指定されたユーザーのセッションで使用されるコマンドシェル
コロンはフィールド区切り記号として使用されます。 このファイルには、ルートスーパーユーザーの説明と、一部のプログラムおよびサービスが起動される特別なユーザーbin、daemon、messagebusが含まれています。
特に重要なのは、非特権ユーザーnobodyです。彼に代わって、組み立てられたシステムコンポーネントの一部のテストを実行します。 このユーザーや他のユーザーのuseraddユーティリティにはまだアクセスできないため、手動で作成します。
ファイル/ 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: > nogroup:x:99: > users:x:999: > EOF
各行は、形式で個別のグループを説明します
<group name>:<group passwd>:<GID>:<users list>
- グループ名-グループのシンボル名
- group passwd-グループパスワード-「x」が含まれます。このフィールドは古く、現在使用されていないためです。
- GID-グループ識別子
- ユーザーリスト-コンマ区切りのユーザーリスト
各グループの目的を簡単に説明してください
- rootは、root特権を持つスーパーユーザーのグループです。 通常の状態では、rootユーザーのみが含まれます
- bin、sys-これらのグループは歴史的に存在するものとして保存されましたが、システムに存在しないプログラムは動作しません
- kmem-カーネルメモリアクセスグループ
- テープ-デバイスノードへのアクセスのグループ
- tty-端末デバイス(コンソールを含む)へのアクセスグループ
- daemon-非特権デーモン起動グループ
- floppy、cdrom、disk-さまざまなタイプのディスクドライブのアクセスグループ
- lp-プリンターのアクセスグループ。歴史的にLPTのパラレルポートに「座っている」。
- ダイヤルアウト-ネットワーク接続中に「ダイヤルアップ」を実行するデバイスへのアクセスのグループ(モデム)
- オーディオ、ビデオ-マルチメディアデバイスへのアクセス
- usb-USBバスアクセスグループ
- adm-/ var / logディレクトリのシステムログを表示するためのアクセスグループ
- messagebus-D-BUSデバイス間のメッセージバスへのアクセスグループ
- systemd-journal-systemdログへのアクセス
- 入力-ユーザー入力デバイスへのアクセス
- メール-メールサービスへのアクセス
- nogroup-空のグループ
- ユーザー-通常、非特権、システムユーザー
ユーザーセッションに再入ることができます
exec /tools/bin/bash --login +h
そして、出来上がり、システムはログインが行われたユーザーの名前を知っています
root:/#
システムに必要ないくつかのログファイルを初期化し、適切な権限を割り当てます
root:/# touch /var/log/{btmp,lastlog,wtmp} root:/# chgrp -v utmp /var/log/lastlog root:/# chmod -v 664 /var/log/lastlog root:/# chmod -v 600 /var/log/btmp
3. GNU環境を構築する長く退屈なプロセス...
この段階は最も手間がかかり、時間がかかります。 GNU環境に必要なすべてのパッケージを手動で収集する必要があります。これは、動作するLinuxシステムを取得できる最小限のプログラムセットです。
収集しているパッケージのリストに沿って移動すると、緊張が高まります。リストは非常に広範囲で、操作はかなり均一です。 ある時点で、私の頭の中で疑問が生じます。一体何が必要なのでしょうか? ここでの主なことは、落胆を乗り越える意志の考えと努力を集めることです。始められたすべてを終わらせなければなりません。
パッケージアセンブリシーケンスは、現在の段階でその実行に必要なすべての依存関係が満たされるように構築されます。 したがって、組立順序に違反してはなりません。
各パッケージの組み立てには、一般的な場合に提供する詳細な指示が伴います
- パッケージソースコードにパッチを適用します。 必要なすべてのパッチは当社によってダウンロードされ、/ sourcesディレクトリにあります
- sedユーティリティによって実行されるソース編集。 ここでは、編集パターンを定義する正規表現の意味を掘り下げることをお勧めします。コマンドの無分別な入力はおそらくエラーにつながるからです。 また、sedはエラーメッセージを表示しません。テンプレートを入力するときに間違えた場合、操作が実行されないか、正しく実行されない可能性があり、ビルドプロセスにとって致命的です。
- 構成 ディレクトリプレフィックスに特に注意-インストール中に、すべての実行可能バイナリ、ライブラリ、およびドキュメントを配置する必要があります。
- バイナリファイルのコピー、ファイルとディレクトリへの権利の割り当て、シンボリックリンクの作成。 一部のリンクは、まだ存在しないFSポイントにつながる可能性があるため、symlink作成コマンドの構文は文字通りに理解され、パスを構築するときにアマチュアアクションを許可しないようにする必要があります。 厳密に指示に従ってください!
そして最後に、最も重要なことはテストです! 一時システムを組み立てる際、テストツールを使用できなかったため、テストを無視しました。次に、テストの必要性がありませんでした。 ここで、システムソフトウェアの最終バージョンを収集するとき、適切に機能するためにアセンブリの結果を包括的にチェックする必要があります。 これは特に、コンパイラー、標準ライブラリー、およびソフトウェア構築用の補助ツール(アセンブラーとリンカー)に当てはまります。
実行すべき指示に注意書きがある場合は、テストをスキップしないでください。 テストには時間がかかります。たとえば、テストを伴うGCCアセンブリは、63 SBU内で行われます。これは私のマシンでは約150分です。 しかし、他に選択肢はありません。
マニュアルには、テストが理由で失敗する可能性のあるメモが含まれています。 テストの完了後、指示に従って期待される結果で結果を検証することが必須です。 バージョンLFS 7.7のすべてのテストの参照ログは、 このリンクにあります
例として、GCCテストログからの抜粋を示します。
GCC簡単なテストログ
=== g ++まとめ===
予想されるパスの数88501
予期しない成功の数2
予想される障害の数443
サポートされていないテストの数3058
/sources/gcc-build/gcc/testsuite/g++/../../xg++ version 4.9.2(GCC)
-=== gccサマリー===
予想パス数106352
予想される障害の数252
サポートされていないテストの数1422
/ソース/ gcc-build / gcc / xgccバージョン4.9.2(GCC)
=== libatomicテスト===
-=== libatomicサマリー===
予想パス数54
=== libgompテスト===
ターゲットUNIXの実行
=== libgompの概要===
予想パス数693
=== libitmテスト===
ターゲットUNIXの実行
=== libitmの概要===
予想パス数26
予想される障害の数3
サポートされていないテストの数1
=== libstdc ++テスト===
-=== libstdc ++サマリー===
予想されるパスの数9925
予想される障害の数41
サポートされていないテストの数233
コンパイラーのバージョン:4.9.2(GCC)
プラットフォーム:x86_64-unknown-linux-gnu
予想されるパスの数88501
予期しない成功の数2
予想される障害の数443
サポートされていないテストの数3058
/sources/gcc-build/gcc/testsuite/g++/../../xg++ version 4.9.2(GCC)
-=== gccサマリー===
予想パス数106352
予想される障害の数252
サポートされていないテストの数1422
/ソース/ gcc-build / gcc / xgccバージョン4.9.2(GCC)
=== libatomicテスト===
-=== libatomicサマリー===
予想パス数54
=== libgompテスト===
ターゲットUNIXの実行
=== libgompの概要===
予想パス数693
=== libitmテスト===
ターゲットUNIXの実行
=== libitmの概要===
予想パス数26
予想される障害の数3
サポートされていないテストの数1
=== libstdc ++テスト===
-=== libstdc ++サマリー===
予想されるパスの数9925
予想される障害の数41
サポートされていないテストの数233
コンパイラーのバージョン:4.9.2(GCC)
プラットフォーム:x86_64-unknown-linux-gnu
サンプルと比較できます
LFS作成者からの公式GCCビルドログ
=== gccの要約===
予想パス数106401
予想される障害の数252
サポートされていないテストの数1404
/ソース/ gcc-build / gcc / xgccバージョン4.9.2(GCC)
make [4]:ディレクトリ '/ sources / gcc-build / gcc'を離れる
-=== g ++サマリー===
予想されるパスの数88501
予期しない成功の数2
予想される障害の数443
サポートされていないテストの数3058
/sources/gcc-build/gcc/testsuite/g++/../../xg++ version 4.9.2(GCC)
-=== libstdc ++サマリー===
予想パス数9835
予想される障害の数41
サポートされていないテストの数278
make [5]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libstdc ++-v3 / testsuite」を終了します
make [4]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libstdc ++-v3 / testsuite」を残します
Pythonでチェックする
-=== libgompの概要===
予想パス数693
make [5]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libgomp / testsuite」を終了します
make [4]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libgomp / testsuite」を終了します
make [4]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libgomp」を入力します
true DO =すべてのマルチDO#make
make [4]:ディレクトリ '/ sources / gcc-build / x86_64-unknown-linux-gnu / libgomp'を離れる
-=== libitmの概要===
予想パス数26
予想される障害の数3
サポートされていないテストの数1
make [5]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libitm / testsuite」を終了します
make [4]:ディレクトリ '/ sources / gcc-build / x86_64-unknown-linux-gnu / libitm / testsuite'を離れる
make [4]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libitm」を入力します
-=== libatomicサマリー===
予想パス数54
make [5]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libatomic / testsuite」を終了します
make [4]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libatomic / testsuite」を終了します
make [4]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libatomic」に入る
true DO =すべてのマルチDO#make
make [4]:ディレクトリ '/ sources / gcc-build / x86_64-unknown-linux-gnu / libatomicを離れる
-=== g ++サマリー===
予想されるパスの数88501
予期しない成功の数2
予想される障害の数443
サポートされていないテストの数3058
/sources/gcc-build/gcc/testsuite/g++/../../xg++ version 4.9.2(GCC)
-=== gccサマリー===
予想パス数106401
予想される障害の数252
サポートされていないテストの数1404
/ソース/ gcc-build / gcc / xgccバージョン4.9.2(GCC)
=== libatomicテスト===
-=== libatomicサマリー===
予想パス数54
=== libgompテスト===
ターゲットUNIXの実行
=== libgompの概要===
予想パス数693
=== libitmテスト===
ターゲットUNIXの実行
=== libitmの概要===
予想パス数26
予想される障害の数3
サポートされていないテストの数1
=== libstdc ++テスト===
-=== libstdc ++サマリー===
予想パス数9835
予想される障害の数41
サポートされていないテストの数278
コンパイラーのバージョン:4.9.2(GCC)
プラットフォーム:x86_64-unknown-linux-gnu
予想パス数106401
予想される障害の数252
サポートされていないテストの数1404
/ソース/ gcc-build / gcc / xgccバージョン4.9.2(GCC)
make [4]:ディレクトリ '/ sources / gcc-build / gcc'を離れる
-=== g ++サマリー===
予想されるパスの数88501
予期しない成功の数2
予想される障害の数443
サポートされていないテストの数3058
/sources/gcc-build/gcc/testsuite/g++/../../xg++ version 4.9.2(GCC)
-=== libstdc ++サマリー===
予想パス数9835
予想される障害の数41
サポートされていないテストの数278
make [5]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libstdc ++-v3 / testsuite」を終了します
make [4]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libstdc ++-v3 / testsuite」を残します
Pythonでチェックする
-=== libgompの概要===
予想パス数693
make [5]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libgomp / testsuite」を終了します
make [4]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libgomp / testsuite」を終了します
make [4]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libgomp」を入力します
true DO =すべてのマルチDO#make
make [4]:ディレクトリ '/ sources / gcc-build / x86_64-unknown-linux-gnu / libgomp'を離れる
-=== libitmの概要===
予想パス数26
予想される障害の数3
サポートされていないテストの数1
make [5]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libitm / testsuite」を終了します
make [4]:ディレクトリ '/ sources / gcc-build / x86_64-unknown-linux-gnu / libitm / testsuite'を離れる
make [4]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libitm」を入力します
-=== libatomicサマリー===
予想パス数54
make [5]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libatomic / testsuite」を終了します
make [4]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libatomic / testsuite」を終了します
make [4]:ディレクトリ「/ sources / gcc-build / x86_64-unknown-linux-gnu / libatomic」に入る
true DO =すべてのマルチDO#make
make [4]:ディレクトリ '/ sources / gcc-build / x86_64-unknown-linux-gnu / libatomicを離れる
-=== g ++サマリー===
予想されるパスの数88501
予期しない成功の数2
予想される障害の数443
サポートされていないテストの数3058
/sources/gcc-build/gcc/testsuite/g++/../../xg++ version 4.9.2(GCC)
-=== gccサマリー===
予想パス数106401
予想される障害の数252
サポートされていないテストの数1404
/ソース/ gcc-build / gcc / xgccバージョン4.9.2(GCC)
=== libatomicテスト===
-=== libatomicサマリー===
予想パス数54
=== libgompテスト===
ターゲットUNIXの実行
=== libgompの概要===
予想パス数693
=== libitmテスト===
ターゲットUNIXの実行
=== libitmの概要===
予想パス数26
予想される障害の数3
サポートされていないテストの数1
=== libstdc ++テスト===
-=== libstdc ++サマリー===
予想パス数9835
予想される障害の数41
サポートされていないテストの数278
コンパイラーのバージョン:4.9.2(GCC)
プラットフォーム:x86_64-unknown-linux-gnu
私は幸運でした-提案された著者とよく一致する結果を得ました。 私もあなたにお願いします。
4.システムの再入力、デバッグ情報のクリア、一時システムの削除
これで、すべてのパッケージが収集されました。 おめでとうございます-旅の中で最も長くて退屈な部分はあなたによって覆われました。 新しいシステムにログインします
# logout # chroot $LFS /tools/bin/env -i \ > HOME=/root TERM=$TERM PS1='\u:\w\$ ' \ > PATH=/bin:/usr/bin:/sbin:/usr/sbin \ > /tools/bin/bash --login
ハッシュを有効にして/ tools / bin / bashを再起動し、パスから/ tools / binディレクトリを削除して実行可能ファイルを検索します。 デバッグ情報を遮断します
# /tools/bin/find /{,usr/}{bin,lib,sbin} -type f \ > -exec /tools/bin/strip --strip-debug '{}' ';'
テスト後に残っているファイルから一時ディレクトリを削除します
# rm -rf /tmp/*
再度ログインし、すでに「ファイティング」バッシュを起動します
# chroot "$LFS" /usr/bin/env -i \ > HOME=/root TERM="$TERM" PS1='\u:\w\$ ' \ > PATH=/bin:/usr/bin:/sbin:/usr/sbin \ > /bin/bash --login
一時的なシステムはもう必要ありません-削除してください
# rm -rf /tools
ふう...主な困難は後ろにあります。ブート、カーネルの構築、ネットワークの構成のためにシステムを構成する必要があります。ただし、これについては最終記事で説明します。
エンディングが続きます...