Apple clang 编译器版本控制架构？

Question

前段时间，GCC >= 5 和 Clang >= 4 编译器更改了其版本号的语义，因此任何非错误修复版本都会增加主要版本号。

就 ABI 兼容性或任何其他范围而言，Apple 是否遵循任何带有 clang 编译器的版本控制架构？我想知道apple-clang 9.0是否ABI兼容9.1等等。

Answer 1

Apple 在每个 Xcode 版本中都会增加其编译器版本号，因此查找 ABI 更改的适当位置是 Xcode release notes。 我能找到的最新 ABI 更改是 Xcode 6：

Xcode 6 中的 libc++ 标头包含一项更改，以使 std::pair 具有一个简单的构造函数。此修复对于性能和符合 C++ 标准很重要，但它使用 std::pair 更改了 C++ 代码的 ABI。

这意味着自 2014 年以来 ABI 没有变化。

编辑：clang 和apple-clang 之间的映射似乎是（取自here 并通过特性测试自己添加了最后一行）：

5.1 -> 3.4
6.0 -> 3.5
7.0 -> 3.7
7.3 -> 3.8
8.0 -> 3.9
9.0 -> 4.0
9.1 -> 5.0

所以我猜，每当苹果在 Xcode 主要版本之间集成来自主线 clang 的更改时，它就会碰撞次要版本的 apple-clang。

但是对于最初的问题，这无关紧要：语言的 ABI 兼容性在他们说之前不会改变，这对于标准库是可能的（但很少发生），对于核心语言来说几乎是不可想象的。对于GCC，苹果甚至guaranteed to not do the latter，但可能在切换到clang时忘记更新文档：

因为 GCC 4.0 符合 Itanium C++ ABI，所以 C++ 对象是 与其他 OS X 编译器构建的对象链接兼容 符合本规范。 Apple 保证未来的版本 OS X 的 GCC 也将符合 Itanium C++ ABI。这意味着 开发人员可以安全地发布动态共享库，其 接口涉及 C++ 类，尽管有一些警告：

• Apple 仅对核心语言功能保证 ABI 稳定性。它 不保证库类的稳定性，包括 std::string、std::map 和 std::ostream 等。

但由于gcc 命令链接到任何最近安装的 Xcode 的 apple-clang，因此该保证也适用于后者。