web-dev-qa-db-ja.com

RPATHを使用しますが、RUNPATHは使用しませんか？

このページ- http://labs.qt.nokia.com/2011/10/28/rpath-and-runpath/ -ld.soでのライブラリ検索の順序について説明しています。

Unless loading object has RUNPATH:
    RPATH of the loading object,
        then the RPATH of its loader (unless it has a RUNPATH), ...,
        until the end of the chain, which is either the executable
        or an object loaded by dlopen
    Unless executable has RUNPATH:
        RPATH of the executable
LD_LIBRARY_PATH
RUNPATH of the loading object
ld.so.cache
default dirs

そして提案する：

バイナリを出荷するときは、RUNPATHではなくRPATHを使用するか、実行する前にLD_LIBRARY_PATHが設定されていることを確認してください。

したがって、RPATHをRUNPATHと一緒に使用すると、RUNPATHの種類がRPATHをキャンセルするため、間接的な動的ロードが期待どおりに機能しないため、不適切ですか？しかし、なぜRPATHはRUNPATHを支持して非推奨になったのですか？

誰かが状況を説明できますか？

clinuxgccshared-librariesdynamic-linking
29
zaharpopov

バイナリを出荷するときは、特にライブラリの検索パスを調整するなど、ユーザーが自分のシステムの詳細にバイナリを適応させる手段を提供することをお勧めします。

ユーザーは通常、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を使用します。

23
chill

チルの答えは正確に正しいです。最近読んだglibcソース（[master 8b0ccb2]、2.17）から、単純に色を追加したかったのです。明確にするために、指定されたレベルで指定された場所にライブラリが見つからない場合は、次のレベルが試行されます。ライブラリが特定のレベルで見つかると、検索は停止します。

ダイナミックライブラリの検索順序：

  1. DT_RUNPATHが設定されていない限り、ELFバイナリのDT_RPATH。
  2. Setuid/setgidでない限り、LD_LIBRARY_PATHエントリ
  3. ELFバイナリのDT_RUNPATH
  4. リンク時に-znodeflibが指定されていない限り、/ etc /ld.so.cacheエントリ
  5. -z nodeflibでない限り、/ lib、/ usr/lib
  6. 完了、「見つかりません」。
15
FDS

しかし、なぜRPATHはRUNPATHを優先して非推奨になったのですか？

DT_RPATHが導入されたとき、それは他のすべてのパラメーターよりも優先されていました。これにより、開発目的であっても、ライブラリの検索パスを上書きすることができなくなりました。そのため、LD_LIBRARY_PATHよりも優先順位が低い別のパラメーターLD_RUNPATHが導入されました。

詳細については、 "共有ライブラリの書き方"Ulrich Drepperによって書かれた作品を参照してください。

8
MichaelGoren