バイナリを出荷するときは、ライブラリの検索パスを調整するなどして、ユーザーが自分のシステムの仕様に合わせてバイナリを調整できる手段を提供することをお勧めします。
ユーザーは通常 LD_LIBRARY_PATH を調整できます そして /etc/ld.so.conf 、どちらも DT_RPATH よりも優先順位が低い 、つまり、バイナリでハードコードされているものをオーバーライドすることはできませんが、 DT_RUNPATH を使用する場合 代わりに、ユーザーは LD_LIBRARY_PATH でオーバーライドできます .
(FWIW、私は ld.so.conf だと思います DT_RUNPATH よりも優先する必要があります 、しかし、とにかく、少なくとも LD_LIBRARY_PATH を取得しました ).
また、 DT_RPATH を使用するという上記の提案には強く反対します . IMO、ネザー DT_RPATH を使用するのが最善です DT_RUNPATH ではない 出荷されたバイナリで。
すべての依存ライブラリを実行可能ファイルとともに出荷し、インストール後に JustWork(tm) を確実に動作させたい場合は、DT_RPATH を使用します。 .
<ブロック引用>
では、なぜ RPATH が推奨されなくなり、RUNPATH が推奨されるようになったのでしょうか?
DT_RPATH が導入されたとき、他のすべてのパラメーターよりも優先されました。これにより、開発目的であってもライブラリ検索パスをオーバーライドすることができなくなりました。そのため、LD_LIBRARY_PATH よりも優先順位の低い別のパラメーター LD_RUNPATH が導入されました。
詳細については、Ulrich Drepper によって書かれた「共有ライブラリの書き方」を参照してください。 .
Chill の答えはまさにそのとおりです。最近読んだ glibc ソース ([master 8b0ccb2]、2.17) から、単純に色を追加したかっただけです。明確にするために、特定のレベルで指定された場所にライブラリが見つからない場合、次のレベルが試行されます。ライブラリが特定のレベルで見つかった場合、検索は停止します。
動的ライブラリ検索順序:
<オール>