1

動的ライブラリ (LINUX の共有ライブラリ) を生成する複数のプロジェクトで構成されるアプリケーションをコンパイルしています。もちろん、そのさまざまなプロジェクトは、私がコンパイルした他のプロジェクトにリンクしています。GCCコンパイラを使用して、UbuntuでCodeBlocks 10を使用しています。

ユーザーによって指定された引数に従って、さまざまなライブラリがロードされるという事実により、私のメインアプリケーションでは、決定に従って、次の行で適切なライブラリをロードしています。

dll = dlopen("my_library.so", RTLD_LAZY);

ドキュメントで指定されているように、ライブラリに他の共有ライブラリへの依存関係があり、プロセスが再帰的に行われる場合、dlopen は自動的にライブラリをロードします。

問題は、dlopen の直後に、何が起こっているのかを理解するために dlerror() を呼び出すと、次のエラーが発生することです。

../../../../gccDebug/os.so : 共有オブジェクト ファイルを開けません: そのようなファイルまたはディレクトリはありません。

エラーを見るだけで、必要以上に2つ下のフォルダーを見ているので、完全に理解しています。問題はなぜですか？

つまり、相対パスを使用して、プロジェクトに共有ライブラリを明示的にロードします。私のメイン アプリケーションでは、ワーキング ディレクトリは ../../gccDebug です。dlopen、mylibrary.so を使用してロードします。これは (プロジェクトのオプションで) ../../gccDebug/gui.so を明示的にロードします。この gui.so は、(プロジェクト オプションで) ../../gccDebug/so.os も明示的にロードします。

それが起こっているように私には思えますが、彼はパスを追加していて、3回目の「反復」で、必要以上に多くのフォルダーをすでに検索しているパスを探しているということです。最初の再帰的読み込み (gui.so) が正常に機能する場合、2 回目の再帰的読み込み (so.os) が奇妙なパスを与えるのはなぜですか??

dlopen 関数を使用した共有ライブラリの再帰的ロードの何が問題になっていますか?

4

1 に答える 1

2

各パスは、ロードを実行するライブラリに相対的である必要があるため../../gccDebug/gui.so、同じディレクトリに何かをロードするには、ロードする必要があります./gui.so

余分なものは、../../gccDebug ../../gccDebug/../../gccDebug ../../../gccDebug`に何かをロードするように指示し../..たためです。../../gccDebug_relative to itself_ which relative to your program's working directory isi.e.

さまざまなライブラリに対してこれを数回行うと、表示され..ている不要なコンポーネントの数が得られます。

gui.so実際にロードされていると確信していますか？リンク時に依存関係をmylibrary.soコピーしたため、実行時にロードする前にそれをロードしようとしていた可能性がありますか?../../gccDebug/os.sogui.sogui.so

ldd mylibrary.soそれが何を見つけようとしているのかを確認したことがありますか？readelf -d mylibrary.soを使用して、ライブラリの動的セクションの内容を表示することもできます。

于 2013-03-07T14:19:40.770 に答える