起動可能な Linux イメージを構築するのに十分な基本的なツールチェーンを構築するために必要な手順を教えてください。
既存のドキュメントへのポインタも非常に高く評価されています。Linux を最初から調べ、ディストリビューション固有のツールを使用して Gentoo イメージをビルドした経験があります。また、組み込みデバイス用のクロス コンパイル ツールチェーンを構築するために使用されるさまざまなツールのドキュメントも参照しました。
ただし、これらのツールのドキュメントでは、これらのツールを実際に使用してツールチェーンをコンパイルする方法についてのみ説明しています。多くの場合、これらのリソースでは、他のツールでは別の方法で (そしてもちろんもっと悪いことも) 行われることが言及されているため、ソースを読むだけでは、実際のプロセスについての洞察が得られるのではなく、指定されたビルド ツールがどのように機能するかを理解するのに役立つだけであり、それは可能であると感じています。変化。
そのため、ツールチェーンの構築を自動化するためのツールに関する議論にはあまり興味がありませんが、代わりに手動で行う方法についてのコメント付きの指示に興味があります。また、今のところ、同じマシンでイメージをビルドして実行する予定であるため、クロスコンパイルする必要はありません。しかし、クロスコンパイルについての議論にはまだ興味がありますが、焦点はおそらく別の場所にあるはずです。他に何が必要で、起動可能なイメージを構築することは、この質問の一部ではありません。そこに到達するためのツールチェーンを構築するだけです。
私の立場を理解していただくために、私が持っているいくつかの質問と、私が知っていると信じているいくつかのことを説明します。後で利用できなくなる可能性があります (他の理由?)。それに応じて環境変数を調整するだけで十分なのか (どれ?)、それともツールチェーンを構築し、chroot して再構築するのが最善なのか (再構築によって何が得られるのか?) はわかりません。前者を実行すると、何が問題になる可能性がありますか? gcc を 2 回ビルドする (最初のビルドを使用して 2 番目をビルドする) のはやり過ぎだと読んだことがあります。もしそうなら、2つのビルドのどのような違いを検出できますか. なぜ彼らは重要なのですか？2 つのビルドが異なる場合は必ず何か問題が発生し、そうである場合はどうすればよいか。適切に実行された場合のクロスコンパイルは、ネイティブに実行された場合とまったく同じバイナリになりますか? そうでない場合、なぜそれがそれほど悪くないのに、多くのプロジェクトがその方法を選択しているのですか?