GCC/Linux：.soに静的ライブラリを追加していますか？

Question

plugin_name.so（通常通り）から関数を動的にロードすることで、プラグインシステムを実装したプログラムがあります。

しかし、私はプラグインのメインプログラムとメイン関数の両方から関数を使用する静的な "ヘルパー"ライブラリ（helper.aと呼ぶことができます）を持っています。彼らはどんな方法でも相互運用する必要はなく、テキスト操作などのためのヘルパー関数です。

このプログラムは、一度起動すると再読み込みや再起動ができないため、メインプログラムからではなく、プラグインから新しい "ヘルパー"機能を期待しています。

私のクエストは..soの "プラグイン関数コード"をメインプログラムとは違う（おそらくもっと新しい）バージョンの "ヘルパー"を使うように強制できますか？

どうすればいいですか？おそらく静的にリンクしたり、helper.aをplugin_name.soに追加することによって、

Answer 1

Nick Meyerの答えはWindowsとAIXでは正しくありますが、他のすべてのUNIXプラットフォームではデフォルトでは正しいとは思われません。

ほとんどのUNIXプラットフォームで

、ランタイム・ローダは、あなたがa.outでfoo_helperを定義するので、もし、すべてのシンボルについて単一名前空間を維持し、またplugin.soで、その後のいずれかからfoo_helperを呼び出し、実行時に見える最初の定義ローダー（通常はa.outから）がにデフォルトで使用されます。が呼び出されます。また

、絵はそれをあなたが-rdynamicフラグを使用しない限り、foo_helperはa.outからエクスポートすることはできません（したがって、ランタイム・ローダには見えないかもしれない）という事実によって複雑、あるいは何らかの他共有ライブラリ参照されます。つまり、がと表示され、Nickがそれらを記述してから、a.outというリンク行に共有ライブラリを追加すると、そのように動作しなくなります。

ELFプラットフォーム（Linuxなど）では、シンボルの可視性とバインディングを大幅に制御できます。リンカのマニュアルページの-fvisibility=hiddenと-rdynamicの説明をGCCのマニュアルページに、また-Bsymbolicを参照してください。

他のほとんどのUNIXプラットフォームには、シンボルのバインディングも制御する方法がありますが、これは必ずプラットフォーム固有のものです。

Answer 2

メインプログラムとダイナミックライブラリが両方とも静的にhelper.aにリンクしている場合、helper.aのバージョンを混在させる心配はありません（ヘルパーで割り当てられたパスポインタのようなことをしない限り.a .exeと.soの境界の間）。

helper.aから必要なコードは、リンクするときに実際のバイナリに挿入されます。したがって、.exeからhelper.aを呼び出すと、実行可能イメージのコードセグメントからコードを実行し、.soからhelper.aを呼び出すと、コードの部分からコードを実行します。 .soがロードされたアドレス空間。 helper.aの中で同じ関数を呼び出す場合でも、呼び出しが.exeか.soかに応じて、その関数の2つの異なる 'インスタンス'を呼び出すことになります。

Answer 3

私はこの質問はあなたと同じだと思います。How to force symbols from a static library to be included in a shared library build?

--whole-archiveリンカオプションはこれを行う必要があります。たとえば、

のgcc -o libmyshared.so foo.oの-lanothersharedlib -Wl、 - 全体 - アーカイブ-lmystaticlib

、それは私のために動作します。