からランタイム未解決のシンボルを持ってここに私の状況は、私は共有ライブラリ（PIC）を持っている動的にロードされたPIC共有ライブラリがNPIC依存
だfoo.so. bar.aのシンボルを使用します。 bar.aはNPICです。したがって、foo.soのリンク行に追加することはできません。
foo.soはmain.Cから動的にロードされます bar.aのシンボルが使用されているときに実行時に正常にロードされますが、未解決のシンボルで終了します。
2ソリューション私は 1.コンパイルbar.a PICを提案し、foo.so 2.のリンク行に追加されました - メインの「-Wl、全アーカイブbar.a -rdynamic」 .C link line
bar.aはサードパーティのライブラリであるため、1は使用できません。 私たちのシンボルを輸出したくないので、2はできません。
この問題を回避する他のイディオム/ソリューションはありますか？
bar.aは第三者であるため "1は不可能です。"
それは私には正しいとは言えません。任意の静的ライブラリをリンクすることができます。そのはです。使用するイディオムです。また、this answerとthis oneを参照してください。
反対。想像してみれば、あなたは、ソースを提供するためのアクセス権がない--fPICオプション。 –
コンスタンチンが言ったこと。私たちは、-fPIC – PdxEngineer
@ ConstantinVladimirovでビルドするソースにアクセスすることはできません.PICは本当に_loader_の問題であり、リンカーの問題ではありません。または私は間違っていますか？ – xtofl
古い良いイディオムが1つあります。それは多くの場合、通常のlibgccのビルドに使用されているので、あなたが
のlibgcc.aからlibgcc_s.soを作成しているとき、私はbar.aあなたを取ると、このラインでbar.so作る、
"libgcc.so idiom"それを呼び出す：
gcc -shared -o bar.so -Wl,--whole-archive bar.a -Wl,--no-whole-archive
-nostdlib程度のものを供給する必要があるかもしれません。
そして今行くと、この新しいbar.so foo.soがロードされたときに今、すべての依存関係は、ダイナミックリンカによって解決されます
でfoo.soリンクします。
bar.soを作成するときに-fPICオプションが必要ですか？ – PdxEngineer
AFAIC no。このオプションはコード生成に関するものですが、ここではコード生成は行われません –
私は右：foo.soとリンクしていないので、dlopenなどで使用するだけですか？ –