1

私のソフトウェア プロジェクト A が共有ライブラリ (libA.so) として出荷されているとします。A は、libA.so をビルドするときに共有ライブラリとしてリンクするサードパーティ ライブラリ B を使用します。(解決策の一部である場合は、libB.so ではなく libB.a を使用しても問題ありません。) B は A によって使用されますが、厳密に言えば、A にリンクするアプリは、 B のシンボルであり、A のパブリック API の一部ではありません。

OK、ここに問題があります。一部のアプリは、独自の理由で B に対しても A に対してもリンクしており、B のバージョン (アプリが使用するバージョンとビルド時にリンクされた A のバージョン) が一致しない場合、シンボルが衝突するとランダムにクラッシュします。

B のすべてのシンボルを A のニーズに合わせて解決し、libA.so で可視シンボルとしてエクスポートしないようにするにはどうすればよいですか? つまり、A に対してリンクするアプリが B のシンボルに対して直接解決されることは望ましくありません。それは可能ですか？

主に、Linux での解決策が必要ですが、OSX や Windows で問題を解決する方法を知っていると、将来的にも役立ちます。

A 自体のシンボルの可視性を制限する方法 (A のパブリック API の一部である必要はない) を理解していますが、依存ライブラリ B に対してこれを行うにはどうすればよいですか?

4

1 に答える 1

1

...一部のアプリは独自の理由でBに対してリンクしています...言い換えると、Aに対してリンクしているアプリがBのシンボルに対して直接解決されることを望んでいません。

考えてみてください。アプリがBのシンボルに対してリンクしないようにすると、アプリは「Bに対してリンクする独自の理由」をどのように満たすでしょうか。

あなたの質問（述べたように）は自己矛盾しています。

現在、同じ実行可能ファイルの異なる部分をリンクするために使用されるBの複数のバージョンは、明らかに問題です。

私が知っている唯一の解決策は、Bを完全に使用しているという事実を「隠す」ことです。そのための方法は次のとおりです。

  1. に対するリンクlibB.a、および
  2. Bのシンボルを内部libA.soに非表示にして、エクスポートされないようにします。これは、リンカーバージョンスクリプトを使用して実現するのが最も簡単です。

libB.aGPLなどで配布されている場合は、そのコピーをに入れると、のライセンス条項libA.soを満たす必要がある場合があることに注意してください。libB注意深く踏み、弁護士に相談してください。

于 2012-05-18T05:50:40.773 に答える