2012-02-06 18 views
5

最近のGCC(4.3.3)を使用しているC++コードベースがありますが、GCC 3.2を使用してビルドされた古いライブラリとリンクする必要があります。 3。利用可能なライブラリの新しいバージョンはありません、私はそれなしで行くことはできません、それは再構築することはできませんので、クローズソースです。C++ ABIを従来のライブラリと組み合わせる

これは、GCC 4.3.3と3.2.3の間にABIの非互換性があるため、問題を引き起こす可能性があるため、私はこれを解決するためのオプションが何であるかを見極めようとしています。

いくつかの追加の詳細:

  • 私は正しいABIのバージョンを取得する-fabi-バージョン= 1で、私のコードベースのすべてを再構築することができますが、私はのlibstdC++バージョン6
  • からいくつかの新しい機能に依存しています
  • コードベース外のすべてのC++ライブラリの依存関係はオープンソースなので、この1つのライブラリを除き、必要に応じて再構築できます。
  • 多くのCライブラリの依存関係は、再構築できないか、再構築が困難です。
  • 古いライブラリは、私がこれまで試してみましたいくつかのlibstdC++バージョン5つの機能

に依存すると思わ:

  • は-fabi-バージョン= 1とリンクを持つすべてのC++コードと依存ライブラリを再構築libstdC++ version 6との互換性がありません。これは、C++の標準ライブラリシンボルのいくつかの未定義のシンボルエラーで失敗します。
  • 上記と同じですが、libstdC++ 5の共有ライブラリにリンクされていますが、これはリンカの問題を解決しますが、実行時に2つのバージョンがレガシーライブラリ内で混在し、クラッシュします。図書館の間で変化する依存関係を満たすために、アプリケーションでC++ ABIのバージョンを混在することが可能にできることを示していると思われるhttp://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

私はこのページを読んで。しかし、私は何かが欠けていない限り、ここでうまくいくとは思われません。

アイデア?

+0

リンカオプション '-Bsymbolic'と' --exclude-libs'は、古いlibstdC++を静的に共有ライブラリにリンクする場合に役立ちます。 –

答えて

3

[OK]を、あなたの回避策があるに:

  • ので、それが動作します3.2.3でコンパイルし、古いC++ライブラリに "C" のインターフェイスを記述します。
  • 新しいコンパイラでCインターフェイスを使用できるようになりました。

C++の「ラッパー」コードをCライブラリとして書くことができますので、C++として使用しますが、このコードは新しいコンパイラでビルドされます。

+1

もちろん、これにはグルーコードを追加することの欠点がありますが、Cコンパイラ/バージョンのすべてのペアで作業する利点があります。 – kibibu

+0

それは合理的なアプローチのようです。私が共有ライブラリを作成しても、以前のlibstdC++共有ライブラリには依然として依存関係があります。私は同じ問題を抱えていませんか?または、古いバージョンで静的にリンクする必要がありますか? –

+0

もう少し掘り下げたら、libstdC++を古いGCCからこの共有ライブラリに静的にリンクするのが適切だと思われます。しかし、これとリンクするだけでは十分ではありません。ライブラリの境界を越えてシンボルが共有されるため、以前と同じ問題が発生することになります。私はあなたがアプリケーション内でdlopenを実行し、RTLD_NOW | RTLD_DEEPBIND | RTLD_LOCAL。 –

関連する問題