使用带有 clang++ -stdlib=libc++ 的 libstdc++ 编译库

Posted 2023-02-14

【中文标题】使用带有 clang++ -stdlib=libc++ 的 libstdc++ 编译库

【英文标题】：Using libstdc++ compiled libraries with clang++ -stdlib=libc++

【发布时间】：2012-09-14 14:39:20

【问题描述】：

我在 Mac OS X (10.8.2) 下使用 C++ 工作，最近我想出了使用 C++11 功能的需求，这些功能可通过使用 libc++ stdlib 的 clang++ 编译器获得。 但是，我还需要使用一些针对 libstdc++（来自 MacPorts）编译和链接的遗留库。

这样做时，我遇到了链接错误，因为使用 std::string 等遗留库的标头需要针对 std::__1::basic_string（即 std::string 的 libc++ 实现）而不是std::basic_string 实现。

有没有办法在开发中混合使用这两个库（例如，通过使用一些预处理器标志？）

【参考方案1】：

您看到的是使用内联命名空间来实现 ABI 版本控制。

这意味着什么：

libstdc++ std::string 是与 libc++ std::string 不同的数据结构。前者是参考计数设计，而后者不是。尽管它们与 API 兼容，但它们与 ABI 不兼容。这意味着，如果您使用 libstdc++ 构造 std::string，然后将其传递给与 libc++ 链接的其他代码，则接收代码会认为它具有 libc++ std::string。 IE。接收者不会知道它应该增加或减少引用计数。

如果没有内联命名空间，结果将是运行时错误。你能期望的最好的结果就是崩溃。使用内联命名空间时，此运行时错误会转换为链接时错误。

对于程序员来说，libstdc++ std::string 和 libc++ std::string 看起来像是同一类型。但是对于链接器来说，它们看起来像是完全不同的类型（线索是 std::__1 命名空间）。并且链接者的观点是正确的。它们是完全不同的类型。

所以是的，您可以操纵一些预处理器标志来链接事物。但是，您将不得不花时间调试由此产生的运行时错误。

做你想做的唯一方法是使这些dylib之间的接口不涉及std::类型，例如string。例如，您可以改为传递 char 的数组。您甚至可以将内存所有权从 libstdc++ 链接的代码转移到 libc++ 链接的代码，反之亦然（它们都将掉入同一个 malloc 池）。

【讨论】：

因此，总而言之，没有希望将遗留库（即与 libstdc++ 链接的库）与 libc++ 一起使用。这确实是一个严重的限制

有一个最大的希望：只要您不跨 dylib 边界传递版本化符号，您就可以在一个进程中混合这两个库。如果你不小心这样做了，错误就会在链接时被发现。您可以跨 dylib 边界抛出std::exception 派生的异常，并跨 dylib 边界转移内存所有权。我怀疑这可能比 gcc 提供自己的 4.2 版本更好的 ABI 兼容性。请注意，根据标准规范，即使 std::string 在 C++98/03 和 C++11 之间也不兼容 ABI。前者被广泛引用，而后者被禁止。

另一个例子：C++11 之前的 gcc std::list 与 std::list 的 C++11 规范不兼容 ABI。换句话说：您对 libc++ 的评论同样适用于（如果不是更多）libstdc++ 的 C++11 之前的版本。 libc++ 与 C++11 之前的 libstdc++ 不兼容的 ABI 并不比符合 C++11 的 libstdc++ 更不兼容。

@user1690715 更准确地说，当它们在其 API 上公开 STL 对象时，针对这两个运行时构建的互通库是没有希望的——这一直是一个非常冒险的提议。跨度>

难道不能为 std::string 创建一个赋值重载到 std::_1::string ，反之亦然吗？