13

libfoo.so.1に依存するライブラリがあるとlddしlibbar.so.1ます。ただし、libbar.so.1現時点では利用できません。libfoo.so.1私のアプリは、まったく必要のない関数を呼び出す必要がありlibbar.so.1ます。

をロードし、関数シンボルを解決してから、依存関係を満たさlibfoo.so.1ずに呼び出す方法はありますか? libbar.so.1「やっていることはわかっているから、もうやらせて」というケースです。RTLD_LAZY フラグを試しましたが、シンボルをロードしないlibbar.so.1前にライブラリをロードしようとします。

編集

これが正確な状況です。

プレイヤーは 3 人です。

  • libbar.so.1LD_LIBRARY_PATHまたは以外のパスldconfigにあり、依存関係がすべて解決されている共有ライブラリ
  • libfoo.so.1は、 とは異なるディレクトリにある共有ライブラリですが、libbarに依存していlibbarます。実行時に、libfooを見つける場所がわかりますlibbar。
  • Applibfoo、実行時のある時点でロードする必要があるバイナリ アプリケーション。

Appを見つける場所はわかりませんがlibbar、知っていることはlibfoo知っています。私が達成しようとしているのは、すべての依存関係を最終的に解決し、すべての人を幸せにするために、の現在の作業ディレクトリを の場所にlibfoo変更するだけの init 関数を持つことです。Applibbar

libfoo最終的にlibbarは、この init 関数ではなく、でものを呼び出す必要があります。シンボルは最終的に実際の関数に解決する必要があるため、スタブの作成は機能しないと思います。

4

5 に答える 5

4

まあ、変数は であっても解決されるRTLD_LAZYので、一般的にはすべてのライブラリをリンクする必要があります。libbar.so.1機能を持たず、リンカーによって検出されるスタブを作成する必要があるようです。

于 2010-01-05T21:30:09.733 に答える
0

libfoo.so.1別の考え：必要な関数をから、.oまたは別のファイルに抽出（ar（1）を使用）してから、.soその抽出ヘルプにリンクしますか？libbar.so.1への参照は、プログラムから（間接的にも）呼び出されないlibfoo関数内にあると想定しています。

于 2010-01-05T21:47:51.830 に答える
0

依存関係の挿入について考えたことはありますか? 同じシグネチャ、パラメーターなどを使用して同一の関数を作成し、リンカーにこの関数を解決させて libbar.so.1 を無視させますか? あなたはこれについて言及していなかったので、私はこれを提案したいと思いました.

これがお役に立てば幸いです。よろしくお願いします、トム。

于 2010-01-05T21:32:14.597 に答える
0

ここでの実際の要件は何ですか？ライブラリをリンクするだけではあまり効果がなく、通常は無害です。ライブラリが不足していませんか？同じ名前のスタブ ライブラリを作成するだけです。ライブラリ内のシンボルの使用を制御または先取りしたいですか? それらを別のライブラリに入れ（正しいバージョンタグを付けて！）、LD_PRELOAD します。

ここでのメタ質問は、依存関係のリンクを先取りできることにどのような価値があるのか​​ わからないということだと思います。それは単なるヘルパー関数です。

于 2010-01-05T21:53:11.820 に答える
-1

dlopen を使用してライブラリをロードし、dlsym を使用して必要な機能を取得します。

于 2010-01-05T21:40:50.603 に答える