コンパイル段階でライブラリの場所をリンクしてもプログラムを実行する前にLD_LIBRARY_PATHを設定する必要があるのはなぜですか？ [コピー]

誰もが口語でコンパイルを使用してソースコードを実行可能ファイルに変換しますが、技術的にはかなり長いパイプラインの1つのステップです。

1. 入力ファイルはプリプロセッサを介して実行され、単一の翻訳単位を生成します。
2. プリプロセッサの出力はアセンブリにコンパイルされます。
3. アセンブラはそれを入力として受け取り、オブジェクトファイルを出力します。
4. リンカはオブジェクトファイルを一緒にリンクして実行ファイルを生成します。

[厳密に言えば、これらのステップを分離する必要はなく、現代のコンパイラは効率のためにしばしばそれらを組み合わせます。 ]

私たちが興味を持っているのは、コードを標準のシステムライブラリと組み合わせるリンクステップです。リンカは、静的ライブラリのオブジェクトを実行可能ファイルに直接コピーします。ただし、共有ライブラリの場合は、ライブラリへの参照のみを提供します。

共有ライブラリには多くの利点があります。プログラムを再コンパイルせずに更新することができ、プログラムが共通のコードを共有できるため、メモリの使用量が少なくなります。また、コードが実行可能ファイルにないという明らかな欠点もあります。

ソリューションは、実行時にすべての共有ライブラリ参照を解決する動的ローダです。ローダーは自動的に実行されます。これを行うためのガイドラインは、リンカが実行可能ファイルに含めることです。もちろん、ローダーがこれらのライブラリを見つけることができると仮定します。

システムライブラリは標準ディレクトリにあるので簡単です。そうでない場合、ローダーはLD_LIBRARY_PATHを検索します。リンカが実行可能ファイルにパスを入力しないのはなぜですか？なぜなら、ライブラリを移動または変更できないからです。

実際、ライブラリはシステム検索パスの外にあるため、実際に実行可能ファイルを移動することもできません。ライブラリが ~luke/lib にある場合にのみ実行される場合、joe がファイルを読み取れないと joe に与えることはできません。新しい職場を救えば、ジョーは迷​​惑になる。

参考までに、他のさまざまな方法で吸収されます。コンパイル時にのみライブラリの場所などを指定できる場合、デバッグは永遠の悪夢になります。