处理 libc++ 和较旧的 libstdc++ 之间的 ABI 差异的好方法是什么？

Question

在 Mac 上处理 libc++ 和 stdlibc++ 之间的 ABI 不一致的好方法是什么（如果有）？

问题：许多 c++11 功能需要 C++ 标准库的新 libc++ 实现。但是 libc++ 与旧的 libstdc++ 不兼容 ABI，而目前大多数软件通常链接到后者。例如，系统编译器仍然使用 stdlibc++，这意味着我所有使用 macports 安装的库对于像字符串这样的标准类都有不同的 ABI，并且无法与大量使用 c++11 的项目链接。

我目前的解决方案：保留两个版本的库，这通常会导致问题（boost、opencv 等）并链接到适当的版本。

我想有人可能会建议，如果我真的想使用 libc++，我应该使用 stdlibc++ 清除我的系统中的任何内容，并确保来自 macports（或其他任何地方）的任何内容仅与 libc++ 链接。您可以看到这项任务看起来是多么艰巨。

有没有人想出一个很好的方法来与我们生活的这个“between-stdlib-limbo”相关联？ :)

编辑：我正在更明确地提出一个隐含的后续问题：Apple 在他们的系统中同时提供了 libc++ 和 libstdc++。假设一个人攻击了根本问题并尝试切换到 libc++-only。鉴于当前安装在系统上的 100% 库（一些随系统附带，其中大部分通过 macports，少数通过手动编译）链接到 libstdc++（如果有的话），从 libstdc++ 切换到 libc++ 的推荐方法是什么)?有没有人这样做并幸存下来？

Answer 1

你不会喜欢这个的。

您根本无法拥有使用其定义在不同系统上更改的类型的 ABI。当您有一个使用 std::string（例如）的 ABI，然后使用不同的编译器或在不同的平台上编译它时，您就是这样做的。

在解决这个问题时，我的首选方法（如果可能的话）是从 ABI 中消除所有编译器特定的内容，并将其替换为本机类型或您的库定义的类型。反过来，这些库定义的类型必须只在 ABI 中公开非编译器的内容。

有时您可以通过简单的替换来解决问题。其他时候你需要采取更激烈的步骤。一种方法可能是围绕std::string 之类的东西提供一种桥接器或包装器类。也许是这样的：

class MyString
{
public:
  virtual const char* c_str() const = 0;
  static MyString* Make();
  virtual MyString* Clone() const = 0;
protected:
  MyString();
};

在图书馆本身：

class MyStringImpl
:
  public MyString
{
public:
  const char* c_str() const
  { 
    return mStr.c_str();
  }

  MyString* Clone() const
  {
    return new MyStringImpl (*this);
  }

  MyStringImpl ()
  {
  }

  MyStringImple (const MyString& rhs)
  :
    mStr (rhs.c_str())
  {
  }
private:
  std::string mStr;
};

MyString* MyString::Make()
{
  return new MyStringImpl;
}

毛。可能效率低下。很多代码要写。但这是你自己画的角落。

Answer 2

除非“隐藏”使用标准库类型，在一个程序中混合使用 libc++ 和 libstdc++ 是完全安全的，其中一些 TU（或库或模块）使用 libc++，而另一些则使用 libstdc++。只要 TU 之间的接口不使用不兼容的类型，就不会有任何问题。

libc++ 使用内联命名空间来帮助确保 ABI 不兼容的类型不会被误认为是另一个；如果接口直接使用 libc++ std::string，则期望 libstdc++ std::string 的库将不会链接到该接口，因为实际符号不同：std::string 与 std::__1::string。

libc++ 还确保异常和动态内存分配等低级功能与 ABI 兼容（假设您使用相同的 abi 库构建 libstdc++ 和 libc++），因此在使用 libc++ 的 TU 中释放内存是安全的。内存是使用 libstdc++ 在 TU 中分配的，或者从基于 libc++ 构建的代码中抛出异常并使用 libstdc++ 在代码中捕获它。

当接口中的类型隐藏标准库类型时可能会出现问题；给定一个使用struct S { std::string s; }; 的接口，S 类型的定义将根据 TU 认为的 std::string 是不同的，因此违反了单一定义规则。

---

不过，您的真正问题似乎在于那些确实在接口中使用标准库类型的库。

我想有人可能会建议，如果我真的想使用 libc++，我应该使用 stdlibc++ 清除我的系统中的任何内容，并确保来自 macports（或其他任何地方）的任何内容仅与 libc++ 链接。您可以看到这项任务看起来是多么艰巨。

您只需要确保在接口中使用标准库的 TU 使用 libc++。您不需要完全清除 libstdc++。在其接口中不使用标准库的库仍然可以继续与 libstdc++ 链接。

编辑：我正在更明确地提出一个隐含的后续问题：Apple 在他们的系统中同时提供 libc++ 和 libstdc++。假设一个人攻击了根本问题并尝试切换到 libc++-only。鉴于当前安装在系统上的 100% 库（一些随系统附带，其中大部分通过 macports，少数通过手动编译）链接到 libstdc++（如果有的话），从 libstdc++ 切换到 libc++ 的推荐方法是什么)?有没有人这样做并幸存下来？

请记住，只有在接口中使用标准库时才重要。希望这些库在为 OS X 构建时已经自行切换到 libc++。如果没有，也许他们会接受补丁来这样做。

使用适当的库构建自己的二进制文件不是“黑客”；如果没有上游项目为您做这件事，这是正确的做法。如果您始终在自己的代码中使用 libc++，那么您将不需要构建任何库的多个版本；只有 libc++ 版本。

---

libc++的abi兼容性参考：http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-September/024594.html