重複の可能性:
GCC 4.0、4.2、および LLVM ABI の互換性
件名によると、両方の C++ ABI は互換性がありますか?
つまり、前者で生成されたバイナリ (共有オブジェクト) を使用して、後者とリンクすることはできますか (逆もまた同様)?
乾杯
重複の可能性:
GCC 4.0、4.2、および LLVM ABI の互換性
件名によると、両方の C++ ABI は互換性がありますか?
つまり、前者で生成されたバイナリ (共有オブジェクト) を使用して、後者とリンクすることはできますか (逆もまた同様)?
乾杯
clang libc++ pageによると、彼らはターゲットにしています
例外オブジェクト、rtti、メモリ割り当てなどの一部の低レベル機能について、gcc の libstdc++ との ABI 互換性。
これは、100% の互換性を目指していないことを暗示しているようです。たとえば、そのページでは次のようにも述べています。
長年の経験 (以前に標準ライブラリを実装したことを含む) から、ABI の破損と実装方法の根本的な変更を必要とする標準コンテナーの実装について多くのことを学びました。たとえば、コピー オン ライト (COW) を使用する代わりに「短い文字列の最適化」を使用して std::string を構築することは、マルチコア マシン (特に右辺値参照を持つ C++'0x) では優れたアプローチであると一般に認められています。ライブラリの古いバージョンとの ABI の互換性を壊すことは、libc++ のパフォーマンス目標を達成するために重要であると判断されました。
GCC はまだ参照カウント COW を使用していると思われるため、clang は ABI との互換性について心配していないようですstd::string
(古い clang コンパイル済みバイナリまたは GCC と)。
相性良さそうです。Clang には独自の C++ ランタイムのプロジェクトもあり、GNU stdlibc++ との低レベルの互換性があると述べています。小さなサンプル プログラムを試してみました。clang ++ で 1 つのファイルをコンパイルし、メイン プログラムと g++ をコンパイルしてリンクしました。ここまでは問題ありませんでしたが、プログラムはかなり単純でした。