libssl.a に静的にリンクする共有オブジェクト A.so と、 libssl.a にも静的にリンクする別の共有オブジェクト B.so があります。
A.so & B.so には、GLOBAL スコープの libssl.a からのシンボルがあります。これを readelf -s A.so で確認しました
A.so と B.so をロードする実行可能ファイル a.out があります。a.out が終了すると、A.so の libssl.a からのシンボルの 1 つで double free エラーが発生します。
libssl.a は各共有オブジェクトに静的にリンクされていますが、それらはグローバルに公開されているため、ローカル コピーを選択する代わりに同じシンボルが共有される可能性があります。
これの回避策は何ですか? ここでシンボルをローカルにする方法は?
助けてください
これは確かに予想されます。の 1 つのインスタンスがlibssl.a他のインスタンス (のサブセットである可能性が高い) を介在させ、結果はきれいではありません。バージョン スクリプト ( --version-scriptto ld、-Wl,for cc) を使用して、A.soおよびからエクスポートされるものを制御できB.soます。何かがエクスポートされていない場合、挿入することもできません。
libssl.aまたは、 のような可視性フラグを使用してコンパイルすることもできます-fvisibility=hidden。これらのフラグは動的リンカーにのみ影響し、静的リンクには影響しません。.a出荷されたファイルには、実行可能ファイルにリンクするための位置依存コードが含まれている傾向があるため、とにかく自分でコンパイルする必要がありました。32 ビット x86 などの一部のプラットフォームのみが、そのようなコードを共有オブジェクトにリンクすることを回避でき、テキストの再配置を犠牲にするだけです。
コメントで提案されている with も機能するはずですが、この目的で使用するのはハックのdlopenようです。RTLD_LOCALdlopen
libssl.so別のオプションは、両方のライブラリで同じ共有を使用することです。