☰

LFSとCLFSが動的リンカーを見つけるために使用されるパスを変更するのはなぜですか？

tag-icon • tag-icon gcc lfs
LFSとCLFSが動的リンカーを見つけるために使用されるパスを変更するのはなぜですか？

両方リニアFSそしてCLFSビルドする前にGCCソースにパッチを適用してください。

CLFSパッチはLFSパッチよりも少し複雑ですが、共通点は動的リンカを見つけるために使用されるパスを変更することです。この場合、新しいバージョンのglibcが構築される場所に移動されます。

少なくともCLFSの場合、クロスツールチェーンを構築しており、おそらくこのチェーンで構築されたものはビルドマシンで実行できないため、GCCにプログラムで次のものを見つけるようにすることには違いはありません。動的リンカー。これは決して起こらないランタイムタスクではありませんか？また、このGCCを使用して共有ライブラリが必要なバイナリをビルドしてターゲットで実行しようとすると、ダイナミックリンカへのパスが間違っていませんか？

また、（C）LFSを使用してを指すようにSTANDARD_STARTFILE_PREFIX_X変更できます$INSTALL_PATH/tools/lib/。これを指定した場合、そのパスは確認されませんか--with-sysroot？--with-sysrootプレフィックスまたは--preint-search-dirs。--with-sysroot

答え1

リンクされたページは、LFS第6章の最終システムを構築するために使用される一時的なツールチェーンを構築するために使用されます。これGCC 6章パッチなしでコンパイルされました。一時ツールバーのパッチは、ホストシステムで使用されるツールに関係なく、パッケージの追加コンパイルを許可するためにのみ使用されます。

答え2

（C）LFSは、ビルドマシンとできるだけ接触の少ないLinuxシステムを構築するために非常に懸命に取り組んでいます。したがって、いくつかのステップは、不要、冗長、または設計されているように見える場合があります。主な問題を解決するCLFSプロセス（一部）は次のとおりです。

  1. Ch5: 交差 binutils
  2. Ch5：初の湾岸交差協力
  3. Ch5：Glibc（クロスコンパイラとターゲットネイティブコンパイラで利用可能）、プレフィックスとしてインストールされています/tools
  4. Ch5：クロスgccの2番目のパスです。動的リンカーパスパッチは、$ CLFSがターゲットファイルシステムのルートである/toolsシンボリックリンクであることを指すようにここに適用されます。$CLFS/tools
  5. Ch6：2番目のcross-gccパスを使用して、ターゲットでデフォルトで実行されているgccのバージョンを含む、ターゲットにデフォルトで提供されるいくつかの新しいツールを構築します。このリストで著しく欠けているのは、glibcの別のコピーです。今は以前のビルドで行われているので、これは必要ありません。
  6. /toolsCh10：ビルドマシンと同じ場所にあるターゲットシステムで起動/chrootします。これにより、以前にビルドされたツール（ネイティブとして）が動的リンカーにアクセスできます。これでglibcを再作成しますが、今回は/usr（代わりに/tools/usr）標準に入ります。

問題の原因は、動的リンカーパスとビルドシステムに関連して発生するという事実に関連しています。答えは、基本的にOP（私）が/ toolsの間にシンボリックリンクがどのように存在するかを考慮せず、${CLFS}/tools/ toolsをリンカのルートパスにするためにパッチを適用したということです。

この質問に対する答えはありませんSTANDARD_STARTFILE_PREFIX_X。

関連情報