Clever Geek Handbook

LFS：フォースのダークサイド。 パート1

まえがき



Linuxをコンピューターにインストールし、特定のタスクにLinuxを使い始めるには多くの方法があります。 ディストリビューションの選択は、「主婦向け」と上級ユーザー向けの両方のあらゆる好みと色に対して非常に広く、特定のハードウェアのソースからのアセンブリを含む、あらゆるレベルのカスタマイズが可能です。 システムのインストールには、原則として、多少なりとも読み書きのできるPCユーザーがアクセスできます。 そして、「Linux vs Other OS」というトピックに関する今日の人気ホリバーに没頭していない場合、このシステムを使用することは、10年前に新しく作られたLinuxoidに必須の知識を必要としません。 私の深く主観的な観点から、このシステムの開発を観察してきた10年以上にわたって、Linuxは初心者にとってより親しみやすくなり、過去に固有の多くの問題を取り除きました。 そしてそれは良いことです。



手作りペンギン...





Habréでは、LFSのテーマに関する2、3の記事が既にちらつきました。たとえばthisやthisです。 後者についてのコメントは論理的なアイデアを示唆しています-Linuxをインストールして調査するための一連の可能性がすでに徹底的に広まっている場合、なぜLFSが必要なのでしょうか？



「宇宙船がどのように耕したのか...そして地球が火の玉だったのか...」についての話はしません。 私は自分の立場に基づいて質問に答えます-私はこれに興味があるだけなので、LFSを収集します。 このプロセスでは、システムの「内部」を確認する良い機会だと思います。 このパスは最適とは言い難いことを認めます。 ただし、この記事とそれ以降の記事では、Linuxシステムを手動で組み立てるプロセスについて説明します。 これらの記事はアセンブリのドキュメントを翻訳しません-これは特に必要ありません。 著者が個人的に直面しなければならなかったプロセスの詳細とニュアンスに重点が置かれます。 このサイクルを初心者の日記のようなものと考えます。





1.システム要件



LFSをビルドするには、GNU / Linux OSがインストールされたコンピューターが必要です。 原則として、任意の分布が適しています。 私のマシンでArch Linuxを使用するとします。 Debianベースのディストリビューション（Linux Mint、Ubuntuなど）についても、もちろん適切ですが、作業の初期段階の1つで、環境変数を初期化するときのコマンドシェル警告 



$ source ~/.bash_profile dircolors: no SHELL environment variable, and no shell type option given


Linux Mint 17で受け取ったこの警告は、ユーザーが再度ログインし、環境変数がsourceコマンドで更新されたときの/ etc / profileからのdircolors（端末を着色するコマンド）の間接呼び出しに関連しています。 これは重要ではなく、無視できます。



ホストLinuxシステムには、 公式のシステム要件にリストされているパッケージがインストールされている必要があります。 これらのパッケージのほとんどは、システムに「そのまま」含まれているか、開発者ツールによって追加インストールされます。 いずれにしても、それらは特定のディストリビューションの公式リポジトリから簡単にインストールできます。 KnoppixタイプのLiveCDを使用することをお勧めします。OSが含まれていないマシンにLFSをインストールできます。 この意味で、選択はあなた次第です。



鉄とOSに加えて、忍耐と忍耐も必要です。 組み立てと構成のプロセスは非常に長く、時間がかかります。 本から端末にコマンドをコピー＆ペーストしないでください。まず、あなたのケースはユニークかもしれません。 第二に、私たちの目標は、ソースからコンパイルされた実行可能なOSを構築するという原則に対処することです。つまり、行われているプロセスの意味を掘り下げる必要があります。 作業の各段階には、急いでせずに有意義にアプローチする必要があります。



2.最小システムアセンブリドキュメント



必要なすべてのドキュメントはLinux Form Scratchブックにまとめられています（リンクから最新の安定版リリースのオンラインバージョンにアクセスできます）。 私が初心者に与えたい最初のアドバイスは、英語の最新の安定版を使用することです。 ロシア語の翻訳がありますが、常に現在のバージョンより遅れています。 さらに、最新のロシア語版のLFS 6.0へのリンクは無効になり、公式サイトから入手できる唯一の翻訳はLFS 5.0に関係しますが、 控えめに言っても時代遅れです。 GNUプロジェクトシステムとソフトウェアのカーネルは定期的に変更されます。さらに、LFSの古いバージョンで説明されているパッケージのバージョンは常にダウンロードできるわけではなく、利用可能な場合は手動で検索する必要があります。 そのため、現在の英語版のLFSを選択します。



注 ：この記事の執筆中に、 LFS 7.3の翻訳へのリンクがLFS のwiki記事で見つかりました 。これは真実に近いものです。 しかし、この翻訳はまだ完全ではありません-本のほとんどは英語です。



また、本の中で現在の開発を使用すると予期せぬ困難につながる可能性があることを読者に警告したいと思います。 このバージョンは、毎日更新されるSVNリポジトリから取得できます。 本はチームによってダウンロードされます 



 $ mkdir ~/LFS && cd ~/LFS $ svn co svn://svn.linuxfromscratch.org/LFS/trunk/BOOK/


そして、このように組み立てるのは簡単です（htmlバージョンをビルドするにはtidyhtmlパッケージが必要です） 

 $ cd BOOK $ mkdir ../html $ make BASEDIR=../html




このバージョンは最新で、最近リリースされたLinux 4.0カーネルの「スカイネットバージョン」の使用に焦点を当てています。



SkyNetはどこにありますか？
しかし：







ダウンロードしたパッケージのチェックサムをチェックするときに最初の問題が発生します 



 $ md5sum -c md5sums . . lfs-bootscripts-20150222.tar.bz2:  . . md5sum: :   1




指定されたアーカイブは解凍され、ファイルサイズは真実に対応します。 おそらく、CRSリストを含むmd5sumsファイルにエラーが忍び込んできたのでしょう。 ただし、リスクを冒さないためには、本の安定版を使用することをお勧めします。



3.土壌の準備



まず、LFSを展開するには、ディスク領域が必要です。 HDD上の1つのパーティション（または複数のパーティション）にすることも、ホストファイルシステム内のディレクトリにすることもできます。 64ビットのArch Linuxが以前にアップロードされた仮想マシンのHDD上のパーティションでオプションを決定しました。



最低限必要なディスク容量は4 GBです。 EXT4でフォーマットして40 GBの論理パーティションを作成しました。 このセクションは、ホストシステムにマウントする必要があります。 マウントポイントを特別な環境変数に保存すると便利です 



 # export LFS=/mnt/lfs


この道に沿って、非常に頻繁に曲がらなければなりません。 コマンドでパーティションをマウントします（私の場合、これはsda6パーティションです。もちろん、あなたのパーティションは異なります） 



 # mkdir -v $LFS # mount /dev/sda6 $LFS




次に、2つのディレクトリを作成する必要があります。$ LFS / sources-tarballをソースとともに保存するため。 $ LFS / tools-一時的なシステム構築ツールの配置用 



 # mkdir -v $LFS/sources # mkdir -v $LFS/tools


$ LFS / sourcesディレクトリに権限を設定します。すべてのユーザーは書き込みを許可されます（+ w）（a）ディレクトリの所有者のみが削除できる機能（t） 



 # chmod -v a+wt $LFS/sources


2つのファイルを$ LFS / sourcesディレクトリにアップロードします-ダウンロード可能なwget-listパッケージのリストとmd5sumsパッケージのチェックサムのリスト 



 # wget http://www.linuxfromscratch.org/lfs/view/stable/wget-list --directory-prefix=$LFS/sources # wget http://www.linuxfromscratch.org/lfs/view/stable/md5sums --directory-prefix=$LFS/sources


--directory-prefixスイッチは、ダウンロードしたファイルを配置するパスを指定します。 その後、すべてのソースとインストールする必要があるすべてのソースのダウンロードを開始します 



 # wget --input-file=$LFS/sources/wget-list --continue --directory-prefix=$LFS/sources


--input-fileスイッチは、ダウンロードされたパッケージのURLのリストを含むファイルを指します。 --continue-ネットワークへの接続が中断された場合、部分的にダウンロードされたファイルのダウンロードを有効にします。 必要なソフトウェアのソースコードを含む約325 MBのアーカイブと、アセンブリに必要なパッチがダウンロードされます。 ダウンロード後、ダウンロードしたパッケージの整合性を確認する必要があります 



 # pushd $LFS/source # md5sum -c md5sums # popd


チェック自体はmd5sumユーティリティの呼び出しです。このユーティリティは、パラメータとして渡されたmd5sumsリストに含まれるすべてのファイルの合計をチェックし、同じリストで指定された値と結果を比較します。 成功した場合、結果は次のようになります



パッケージの整合性チェック結果
acl-2.2.52.src.tar.gz：ゴール

attr-2.4.47.src.tar.gz：ゴール

autoconf-2.69.tar.xz：ゴール

automake-1.15.tar.xz：ゴール

bash-4.3.30.tar.gz：ゴール

bc-1.06.95.tar.bz2：目標

binutils-2.25.tar.bz2：目標

bison-3.0.4.tar.xz：ゴール

bzip2-1.0.6.tar.gz：目標

check-0.9.14.tar.gz：ゴール

coreutils-8.23.tar.xz：ゴール

dejagnu-1.5.2.tar.gz：目標

diffutils-3.3.tar.xz：ゴール

eudev-2.1.1.tar.gz：目標

eudev-2.1.1-manpages.tar.bz2：ゴール

e2fsprogs-1.42.12.tar.gz：目標

expat-2.1.0.tar.gz：ゴール

expect5.45.tar.gz：ゴール

file-5.22.tar.gz：ゴール

findutils-4.4.2.tar.gz：目標

flex-2.5.39.tar.bz2：目標

gawk-4.1.1.tar.xz：目標

gcc-4.9.2.tar.bz2：目標

gdbm-1.11.tar.gz：ゴール

gettext-0.19.4.tar.xz：目標

glibc-2.21.tar.xz：目標

gmp-6.0.0a.tar.xz：目標

gperf-3.0.4.tar.gz：目標

grep-2.21.tar.xz：目標

groff-1.22.3.tar.gz：ゴール

grub-2.02〜beta2.tar.xz：ゴール

gzip-1.6.tar.xz：ゴール

iana-etc-2.30.tar.bz2：ゴール

inetutils-1.9.2.tar.gz：ゴール

intltool-0.50.2.tar.gz：ゴール

iproute2-3.19.0.tar.xz：ゴール

kbd-2.0.2.tar.gz：目標

kmod-19.tar.xz：目標

less-458.tar.gz：ゴール

lfs-bootscripts-20150222.tar.bz2：目標

libcap-2.24.tar.xz：ゴール

libpipeline-1.4.0.tar.gz：ゴール

libtool-2.4.6.tar.xz：ゴール

linux-3.19.tar.xz：ゴール

m4-1.4.17.tar.xz：目標

make-4.1.tar.bz2：ゴール

man-db-2.7.1.tar.xz：目標

man-pages-3.79.tar.xz：目標

mpc-1.0.2.tar.gz：目標

mpfr-3.1.2.tar.xz：目標

ncurses-5.9.tar.gz：目標

patch-2.7.4.tar.xz：ゴール

perl-5.20.2.tar.bz2：目標

pkg-config-0.28.tar.gz：ゴール

procps-ng-3.3.10.tar.xz：目標

psmisc-22.21.tar.gz：目標

readline-6.3.tar.gz：目標

sed-4.2.2.tar.bz2：目標

shadow-4.2.1.tar.xz：ゴール

sysklogd-1.5.1.tar.gz：ゴール

sysvinit-2.88dsf.tar.bz2：ゴール

tar-1.28.tar.xz：ゴール

tcl8.6.3-src.tar.gz：ゴール

texinfo-5.2.tar.xz：目標

tzdata2015a.tar.gz：目標

udev-lfs-20140408.tar.bz2：目標

util-linux-2.26.tar.xz：ゴール

vim-7.4.tar.bz2：目標

XML-Parser-2.44.tar.gz：ゴール

xz-5.2.0.tar.xz：目標

zlib-1.2.8.tar.xz：目標

bash-4.3.30-upstream_fixes-1.patch：ゴール

bc-1.06.95-memory_leak-1.patch：ゴール

bzip2-1.0.6-install_docs-1.patch：ゴール

coreutils-8.23-i18n-1.patch：ゴール

glibc-2.21-fhs-1.patch：ゴール

kbd-2.0.2-backspace-1.patch：ゴール

mpfr-3.1.2-upstream_fixes-3.patch：ゴール

readline-6.3-upstream_fixes-3.patch：ゴール

sysvinit-2.88dsf-consolidated-1.patch：ゴール



いくつかのpushd / popdコマンドに特別な注意を払いました。 私は長い間このシステムを使用していると確信しているLinuxoidですが、これらの内部bashコマンドは私にとって新しいものです。 それでも、ファイルシステムのさまざまなポイントにダウンロードしてから戻る必要がある場合に非常に便利です。 pushdコマンドは、パラメーターで指定されたディレクトリに一時的に移動します。 戻るには、popdコマンドを使用します。 この場合、ジャンプするルートはスタックの形式で編成され、戻る必要があるパスを再入力する必要はありません。



これで、アセンブリを開始するために必要なものはすべて揃いましたが、最後の準備作業を完了する必要があります



4.作業環境のセットアップ



まず、ホストシステムのルートにある$ LFS / toolsディレクトリへのシンボリックリンクを作成します。 



 # ln -sv $LFS/tools /


なぜこれが必要なのですか？ 一般に、なぜシンボリックリンクが必要なのですか？ ファイルシステム内の特定のポイントへの均一なアクセスを保証するために作成されます。 現在、システムホストでは、このディレクトリへのパスは/ mnt / lfs / toolsのようになります。 ルートがpath / mnt / lfsにある一時システムに移動すると、この一時システムでは、ディレクトリの内容がpath / toolsで利用可能になります。 収集する主なツールは、実行場所に関係なく、/ toolsパスに沿ってこのディレクトリにアクセスします-このパスはコンパイル後にバイナリに組み込まれます。 したがって、指定されたリンクを作成すると、システムルートの現在の場所に関係なく、/ toolsパスに沿ってこのディレクトリにアクセスできるようになります。 そうしないと、一時システムへの移行直後に、最初のコンパイルでエラーが発生します。



次に、新しいグループと新しいユーザーを作成します。これらのユーザーに代わって、一時的なシステムアセンブリの最初の段階で作業します。 絶対にrootとして作業するべきではありません-例えば、インストールされたパッケージを構成するとき、ホストシステムにアセンブルされたパッケージをインストールすることにより、インストールディレクトリのプレフィックスを設定したり、パッケージを壊す（またはパッケージマネージャーの作業を複雑にする）ことを混同したり忘れたりする可能性があります。 トラブルを避けるために、特定のディレクトリのみへの書き込み権限を持つ非特権ユーザーからの作業が設定されています。 



 # groupadd lfs # useradd -s /bin/bash -g lfs -m -k /dev/null lfs


最初のコマンドは、lfsグループを作成します。 2番目-ユーザーlfsを作成します。 パラメーターの意味は次のとおりです。







ユーザーlfsのパスワードを設定します 

 # passwd lfs


$ LFS / sourcesおよび$ LFS / toolsディレクトリの所有者にします 



 # chown -v lfs $LFS/sources # chown -v lfs $LFS/tools




lfsとしてログイン 



 # su - lfs


コマンドパラメーターのダッシュ（ -lまたは--loginスイッチの省略形）は、このユーザーに対して、以前のセッションから環境変数の値を継承しない「クリーン」セッションを作成する必要があることを示します。 このセッションでは、独自の環境変数セットを作成します



ユーザーのホームディレクトリにファイルを作成する



〜/ .bash_profile 

 [lfs@arch-guest ~]/$ cat > ~/.bash_profile << "EOF" > exec env -i HOME=$HOME TERM=$TERM PS1='\u:w\$ ' /bin/bash > EOF


〜/ .bashrc 

 [lfs@arch-guest ~]/$ cat > ~/.bashrc << "EOF" > set +h > umask 022 > LFS=/mnt/lfs > LC_ALL=POSIX > LFS_TGT=$(uname -m)-lfs-linux-gnu > PATH=/tools/bin:/bin:/usr/bin > export LFS LC_ALL LFS_TGT PATH > EOF




〜/ .bash_profileファイルは、環境変数の個々のユーザー設定を定義します。 チーム 



 exec env -i HOME=$HOME TERM=$TERM PS1='\u:W\$ ' /bin/bash


環境変数に値を割り当てることにより、「クリーンな」ユーザー環境を作成します（ -iスイッチは以前の設定を無視します）







〜/ .bashrcファイルは、指定されたユーザーのセッションにログインするときにどの設定を行う必要があるかを決定します







それとは別に、ファイルの作成方法に注意する必要があります。 catコマンドを使用する理由、お気に入りのコンソールエディターを使用できない理由 ホストシステムにいる間は、テキストエディターを使用できます。 しかし、一時システムに移行するときには、エディターはありません。 したがって、catコマンドを使用する必要があります。このコマンドは、出力ストリームをあるファイルから別のファイルにリダイレクトします。 入力ファイルはここでは指定されません-これは標準入力ストリームが使用されることを意味します。 出力ファイルは、作成するファイルであり、終了条件は、ファイルの終わりの文字シーケンス（EOF）の入力ストリームでの出現です。 コマンドを入力すると、作成されたファイルのテキストをターミナルに直接入力できます。 プロセスを終了するには、EOF行を入力します。 このようにして、シェルをプリミティブテキストエディターに変えます。



作成されたスクリプトは、lfsに代わってログインごとに実行されます。 次のコマンドでユーザー環境を更新します 



 [lfs@arch-guest ~]/$ source ~/.bash_profile




必要な環境変数が設定されていることを確認します 

 [lfs@arch-guest~]/$ set




5.ツールの一時セットの組み立て（一時システム）



システムの組み立てを開始すると、「鶏と卵」という古典的な問題に直面します。 システムを構築するには、コンパイラ、リンカ、およびライブラリが必要です。 ただし、上記のソースコードはありません。 ホストシステムにコンパイラがあり、それらに必要なソフトウェアの収集を開始します。 ただし、同じgccをデフォルト設定で単純に構築する場合、構築の初期段階ではLFSシステムで動作しません-操作に必要なライブラリの動的リンクを使用します。 作業に必要なすべてのコードは、静的にビルドする必要があります。つまり、実行可能ファイルに明示的に含める必要があります。



したがって、最初に、最終バージョンをアセンブルするときにそれらを使用できるように、将来のシステムの一部をクロスコンパイルします。



一時システムの構築に関するすべての作業は、$ LFS / sourcesディレクトリで行われるため、そこに行きます 



 [lfs@arch-guest ~]/$ cd $LFS/sources


コンパイルされたすべてのパッケージについて、アセンブリの順序には次の一連のアクションが含まれます（特に指定されていない場合）。







パッケージのアセンブリ時間はさまざまです-ほぼ瞬時から2時間半です（「悪魔」の後にgccをビルドすると、すべてのテストがほぼ同じ時間続きます）。 コンピューターのパフォーマンスはさまざまであるため、標準ビルド単位（SBU）と呼ばれる相対的な単位がアセンブリ時間の単位として選択されます。 1つのSBUはbinutilsパッケージのビルド時間に等しく、最初にコンパイルされます。 1.0 SBUの継続時間はシステムで見積もることができますが、その詳細は以下のとおりですが、現時点では



推奨事項 ：システムを複数のスレッドにアセンブルしないでください。 マルチコアプロセッサを使用している場合、-jスイッチを使用すると作業が高速化されますが、後で重要なテストが失敗したり、アセンブルされたソフトウェアの動作が不安定になったりする場合があります。 1つのスレッドでのアセンブリはそれほど長くはありません。マルチスレッドアセンブリによって獲得された問題を解決するために、より多くの時間が費やされます。



各パッケージのアセンブリは考慮しません。これはLFSブックそのものです。 ただし、最も重要なパッケージのコンパイルを考慮して、アセンブリのニュアンスに焦点を当てます



6. Binutilsのビルド-最初のパス。 SBU測定



Binutilsは、ソフトウェアを構築するためのユーティリティツールを含むパッケージです。 これらには、アセンブラー（as）およびリンカー（ld）が含まれます。 glibcとgccはいくつかのテストに合格するために必要なので、このパッケージが最初にビルドされます。



アーカイブを解凍し、その内容が含まれるディレクトリに移動します 



 $ tar -pxf binutils-2.25.tar.bz2 $ cd binutils-2.25




このパッケージをビルドするには、別のディレクトリを作成して作成し、そこに行くことをお勧めします 



 $ mkdir -v ../binutils-build $ cd ../binutils-build




次に、正しいMakefileを生成するようにパッケージを構成する必要があります。 



 $ ../binutils-2.25/configure \ > --prefix=/tools \ > --with-sysroot=$LFS \ > --with-lib-path=/tools/lib \ > --target=$LFS_TGT \ > --disable-nls \ > --disable-werror




キーへの特別な注意：







コンフィギュレーターが機能した後、出力でパッケージをビルドおよびインストールするように設計されたMakefileを取得します。 パッケージを収集し、SBUを測定します 



 $ time { make; }


time {...}ユーティリティを使用して時間を測定します。このユーティリティは、中括弧で囲まれたコマンドの実行時間を返します。 これにより、残りのパッケージのビルド時間を把握するために、SBUを暫定的に評価する機会が提供されます。



注 ：LFSでは、アセンブリとインストールの構成時間を測定することをお勧めします。 しかし、この推奨事項は膨大です。 マシンがメイクとテストに費やす時間のほとんど。 さらに、makeとmake installの間に、掘り下げなければならない他のアクションを実行できます。 そこで、他の作業によるシステムの全体的な負荷によって決定される測定の近似的な性質を考慮して、上記のように評価を実行することにしました。



私のシステムの場合-4096 MBのRAMを搭載した4つのIntel Core i7コアと16 GBのRAMを搭載した同じIntel Core i7-2600K（ハイパートレーディングを備えた4つのコア）でホスト上で実行される仮想マシン-SBUは組み込み時に2分32秒でした1つのスレッド。



残りのパッケージのビルド時間はSBUの一部で本に示されているため、この方法で計画して、他のすべての概算ビルド時間を見積もることができます（たとえば、テストと一緒にgccの最終ビルドを開始し、63 SBUを要するため、他のことをするために出発します-いいえ）画面を見つめながら希望を感じる）



アセンブリが完了したら、ライブラリディレクトリへのシンボリックリンクを作成します。システムが64ビットの場合、この操作が必要です。したがって、次のコマンドは最初にシステムの容量をチェックし、必要な場合にのみシンボリックリンクを作成します。 



 $ case $(uname -m) in > x86_64) mkdir -v /tools/lib && ln -sv lib /tools/lib64 ;; > esac


その後、組み立てられた 



 $ make install


上がって不要なディレクトリを削除します 



 $ cd .. $ rm -r binutils-2.25 $ rm -r binutils-build




7. GCCアセンブリ-最初のパス



システムの構築プロセスでは、コンパイラを3回組み立てる必要があります。最初の2つのパスは、ホストシステムとは独立して動作できるコンパイラを取得するために必要です。最初のパスでは、必要なすべてのコードの静的レイアウトを使用し、いくつかの追加設定を実行します。



最初に、ソースでアーカイブを解凍し、作成されたディレクトリに移動します 



 $ tar -pxf gcc-4.9.2.tar.bz2 $ cd ../gcc-4.9.2




コンパイルを成功させるには、GMP、MPFR、MPCの3つのパッケージのソースコードが必要です。それらをコンパイラのソースディレクトリに展開し、gccソースで参照されているディレクトリの名前を変更します。 



 $ tar -pxf ../gmp-6.0.0a.tar.xz $ tar -pxf ../mpfr-3.1.2.tar.xz $ tar -pxf ../mpc-1.0.2.tar.gz $ mv -v gmp-6.0.0a gmp $ mv -v mpfr-3.1.2 mpfr $ mv -v mpc-1.0.2 mpc


さらに、gccソースを編集する必要があります。実際、それらのldリンカー検索パスは、通常の作業システム用として定義されています。この場合、リンカーは/ toolsディレクトリにあります（binutilsの一部としてコンパイルされました）。一部のマクロ定義も/ toolsを参照する必要があるため、モンスターコマンドを使用してソースコードを変換します。 



 $ for file in \ > $(find gcc/config -name linux64.h -o -name linux.h -o -name sysv4.h) > do > cp -uv $file{,.orig} > sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&@g' \ > -e 's@/usr@/tools@g' $file.orig > $file > echo ' > #undef STANDARD_STARTFILE_PREFIX_1 > #undef STANDARD_STARTFILE_PREFIX_2 > #define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/" > #define STANDARD_STARTFILE_PREFIX_2 ""' >> $file > touch $file.orig > done


うーん...このチームの最初の外観は私を怖がらせました。実際、ここでファイルinux64.h、linux.h、sysv4.hは、gcc / configディレクトリにある場合、ループでソートされます。それらはそれぞれ、接尾辞* .orig（ソースのオリジナルを保存します-その後、sedの入力ストリームとして設定されます）で新しいファイルにコピーされ、見つかった各ファイルで/ tools置換がldリンカー検索パスに対して実行され、/ usrが置き換えられます/ツール。さらに、マクロは、STANDARD_STARTFILE_PREFIX_1およびSTANDARD_STARTFILE_PREFIX_2をオーバーライドして、正しいライブラリパスを指すように各ファイルの末尾に追加されます。次に、touchコマンドは、処理されたすべてのファイルの最後の変更時刻を現在のファイルに変更し、cpコマンドの-uスイッチ（ソースファイルが宛先ファイルよりも新しい場合はコピー）と組み合わせることで、コマンドが繰り返し実行される場合に不要な変更を防ぎます。



この例のsed構文に関するいくつかの言葉
sed — , , .



LFS, sed , .



  • "/", sed "@"

  • "\(64\)\?" "\(32\)\?" sed-, , «64» «32» — .

  • "&" , /tools ( "&" )





's@/lib\(64\)\?\(32\)\?/ld@/tools&@g' — , "/lib", "/lib64" "/lib32" "/tools", 's@/usr@/tools@g' — , "/usr" "/tools"





一般に、一時的なシステム（およびメインシステム）のアセンブリは、そのような構造の使用で文字通り飽和しています。それらの意味を理解し、チームを手で満たすことをお勧めします。次に、アセンブリプロセスが終了するまでに、ワードプロセッシング技術と* nixコンソールでの作業に関する多くの問題について理解します。



次のコマンド： 



 $ sed -i '/k prot/agcc_cv_libc_provides_ssp=yes' gcc/configure


configuratorスクリプトを修正しますが、私の場合は変更しませんでした。本によると、スタック保護でgccの性質を変えることを目指しています。



次に設定する必要があります 



 $ ../gcc-4.9.2/configure \ > --target=$LFS_TGT \ > --prefix=/tools \ > --with-sysroot=$LFS \ > --with-newlib \ > --without-headers \ > --with-local-prefix=/tools \ > --with-native-system-header-dir=/tools/include \ > --disable-nls \ > --disable-shared \ > --disable-multilib \ > --disable-decimal-float \ > --disable-threads \ > --disable-libatomic \ > --disable-libgomp \ > --disable-libitm \ > --disable-libquadmath \ > --disable-libsanitizer \ > --disable-libssp \ > --disable-libvtv \ > --disable-libcilkrts \ > --disable-libstdc++-v3 \ > --enable-languages=c,c++




キーには次の意味があります。







この方法でアセンブリを構成したら、それを実行してパッケージをインストールします 

 $ make $ make install




その後、私たちは自分の後をきれいにします 

 $ cd .. $ rm -r gcc-build && rm -r gcc-4.9.2


8.一時システムの残りのパッケージをビルドします



一時システムの以降のアセンブリプロセスについては、説明は不要です。読者にLFSブックを参照してください。注目に値する唯一のことは、プロセス全体を通してソースを編集し、特別なコンフィギュレーターオプションをインストールする必要があることです。このプロセスは思慮深く、ゆったりとする必要があります。この段階での間違いは非常に費用がかかる可能性があり、準備ができていないNewfagであるそれを見つけることは非常に困難です。



一時的なシステムの最小限のパケットセットの説明といくつかの重要な説明に限定されます。gccに続いて、インストールする必要があります







9.デバッグ情報のトリミング



すべてを収集したら、スペースを節約するために、収集したバイナリからデバッグ情報を削除することをお勧めします。チームでやる 



 $ strip --strip-debug /tools/lib/* $ /usr/bin/strip --strip-unneeded /tools/{,s}bin/*




さらに、インストールされたドキュメントを削除できますが、まだ必要ではありません-とにかく、それは収集され、再びインストールされ、すでに最終的に 



 $ rm -rf /tools/{,share}/{info,man,doc}




まとめ



その結果、一時的なシステムが$ LFS / toolsディレクトリに配置されました。これは、GNU環境とシステム構成の最終的なアセンブリの次のステップに進みます。ただし、これについては後で説明します。



私の著作にご注目いただきありがとうございます！



続行するには...


More articles:


All Articles