5

パスのリストを取得するための最もポータブルで堅牢な方法は何/etc/ld.so.confですか？それによって構成され、そこから含まれるファイルは何ですか？ファイルを手動で解析することはお勧めできません—フォーマットは将来のリビジョンで変更される可能性があります。

質問をよりよく理解できるように、以下に具体的な詳細を示します。これらの詳細にもかかわらず、これは一般的なプログラミングの質問であり、他の状況に適用できることに注意してください。

LuaRocksと呼ばれるプログラムがあります。これは、Luaプログラミング言語（Ruby gemやPythoneggsのようなもの）のパッケージマネージャーです。LuaRocksパッケージは「ロック」と呼ばれます。

便利な機能として、LuaRocksを使用すると、ロックの作成者は、Cヘッダーファイルやダイナミックライブラリファイルのリストとして作成された、ロックの外部依存関係のリストを指定できます。（Linuxでは.so。）指定されたファイルが存在しない場合、ロックをインストールできません。

現在、Linuxでは、LuaRocksはデフォルトで2つのハードコードされたパスでファイルを検索することによって.soファイルの存在をチェック/usr/libします/usr/local/lib。

これは間違った振る舞いであり、Ubuntuや他のDebianディストリビューションの最近の変更によって壊れていると思います。

更新：パス自体はハードコーディングされていませんが、構成ファイルでユーザーが構成できます。それでも、IMOは最善の解決策ではありません。

代わりに（私が理解しているように）、LuaRocksは、パスで指定された/etc/ld.so.confファイルとそこに含まれるファイルを検索する必要があります。

（今、上記の質問をもう一度読んでください;-)）

4

2 に答える 2

7

/etc/ld.so.confまたは構成ファイルを解析する必要はありません。「ldconfig」を実行すると、構成されたディレクトリがスキャンされ、キャッシュファイルが生成されます。

その後、dlopenを試行すると、キャッシュされたライブラリディレクトリを反復処理することにより、ファイルが自動的に検索されます。コンパイルして-lSomeLibを指定する場合と同じように、ld.so.conf（.d）で構成されている場合は、-L / my / other/pathを指定する必要はありません。

autoconfは、共有ライブラリにリンクするテストプログラムをコンパイルしようとすることでこれを実現しますが、これはdlopen（）呼び出しの機能的なラッパーにすぎません。

したがって、他のメソッドは必ずしも「間違っている」とは限りませんが、そのルートでライブラリにリンクしようとしたり、dlopen（）を実行したりするのが「最も正しい」方法です。

これを考慮してください。ISNが/etc/ld.so.cacheにキャッシュされていないディレクトリ内のライブラリにリンクしようとすると、プログラムを実行しようとすると、dlopen（）ができないため、失敗します。図書館！

したがって、「適切な」共有ライブラリはすべて/etc/ld.so.cacheにあり、linkable / dlopen（）ableになります。これは、gccがそれを使用してリンクできること、およびユーザー生成ライブラリまたは実行可能ファイルがリンクできることを意味します。実行時に開きます。

これは、環境変数LD_LIBRARY_PATHまたはLD_PRELOAD_PATHを明示的に設定することで回避できますが、それぞれに独自の注意事項があるため、「標準」で使用する場合は避ける必要があります。

共有ライブラリの作成に関する優れた記事は、これらの問題のいくつかをカバーしており、他の共有ライブラリのプログラムによる消費に取り組んでいる人にとっては良い読み物です。ウルリッヒドレッパーの共有ライブラリの書き方。

于 2011-07-11T18:07:00.497 に答える
2

FHSによると、ダイナミックライブラリの有効な場所は次のとおりです。

/lib*/
/opt/*/lib*/
/usr/lib*/
/usr/local/lib*/

（そしておそらく~/lib*/同様に。）

私のすべてのエントリは/etc/ld.so.conf.d/*これに準拠しています。一部のエントリは、FHSディレクトリの下のサブディレクトリを参照しています。これは、パス情報なしでそこにあるライブラリを使用できることを意味します。

今、私はLuaRocksについて十分に知りません。Lua-pathスタイルのグロブ（のみ?）に制限されている場合、これらを一致させることはできず、構成を解析する必要があります。それ以外の場合は、これらのディレクトリのどこかでそれらを見つけようとすることができます。

これは、FHSに準拠していないシステム（オプションのみ：構成の解析）で機能しなくなります。ディレクトリが構成に含まれていない場合、インストーラーはリンカーが検出できないライブラリを参照する可能性があります。

これらの2つは私には受け入れられるように思われるので、構成を無視してこれらのdirを確認します。

（別の可能性として、ライブラリをリンクしようとしている可能性があります。これは自動的に正しいパスを使用する必要があります。ただし、これはプラットフォーム固有であり、危険な場合があります。）

于 2011-07-11T18:02:25.247 に答える