1

dlopen共有ライブラリ libB.so を開くために使用する実行可能ファイル A があります(同じディレクトリにあるため、LD_LIBRARY_PATH=. を実行してプログラムに適切に見つけさせます)。このライブラリ libB.so は、同じディレクトリにある libC.so でそのシンボルの一部を見つけることになっています。

ただし、 /usr/lib64 には libC.so もあり (これは異なるパラメーターでコンパイルされているため、同じシンボルはありません)、不明な理由で、libB.so は 1 つの代わりにこれを開こうとします。つまり、同じディレクトリにあります。私がするとき、私はの代わりにldd libB.so見ることができます。libC.so => /usr/lib64/libC.solibC.so => /path/to/program/A/libC.so

libB.so でこのリンクを変更する方法はありますか (可能であれば再コンパイルせずに)、または libB.so を再コンパイルする必要がある場合、コンパイラが他のものではなく /usr/lib64 で libC.so を使用することを選択した理由は何ですか?

(注: 私はプラットフォームの管理者ではないため、/usr/lib64 の libC.so を置き換えることはできません)

ありがとう

4

2 に答える 2

0

マンページを正しく理解していれば、LD_LIBRARY_PATHがのようなシステム全体のパスに取って代わるはずな/usr/lib64ので、なぜこれが機能しないのかわかりません。

setuid / setgidプログラムですか？LD_LIBRARY_PATHはそれらに対して無視されます。

現在のパス（.）が変更され、LD_LIBRARY_PATH=.libBがlibCを検出できなくなりましたか？

プログラムをstraceで実行すると、lddがlibCをチェックしているディレクトリが表示されます。これは、どこでどのように検索しているかをデバッグするのに役立つ場合があります。

于 2012-07-31T16:13:42.817 に答える
0

私は問題が何であるかを理解しました.私はスーパーコンピューターで実行しています.もちろん、プログラムが実際に実行される前に、環境変数を使用してバックグラウンドでいくつかのことが行われます. これは私の共有ライブラリを台無しにしていました。

于 2012-07-31T16:24:55.060 に答える