Debian附带了C ++共享库，即libboost等...使用这两种编译器进行编译，使用这两种编译器的用户程序通常都可以正常工作，并且库名称不会被用于它们的编译器损坏。当你安装clang时，debian不会去你系统上安装的每个C ++库的重复版本。
这笔交易是什么？ clang与发行版提供的C ++库链接的能力是否比编译器开发人员描述的那样强大（谢天谢地）？
答案 0 :(得分：25)
即使是像标准容器那样核心的东西
标准容器并非都是“核心”。 （对于典型的实现），它们完全在头文件中的有效C ++中实现，如果使用G ++和Clang ++编译相同的头文件，您将获得ABI兼容输出。如果您使用不同版本的容器标头，而不仅仅是使用Clang而不是GCC，那么您应该只“兼容”标准容器的核心内容“。
GCC和Clang都符合跨厂商，跨平台C++ ABI（最初是为Itanium架构开发的，但也用于x86，x86_64，SPARC等）真的 ABI指定了类布局，名称修改，异常处理，vtable等核心内容，Clang和GCC都遵循它。
换句话说，如果你使用GCC和Clang编译相同的源代码，你将获得与ABI兼容的二进制文件。
如果您想更好地了解这些内容，请参阅我的What's an ABI and why is it so complicated?幻灯片。
答案 1 :(得分：21)
G ++和Clang绝大多数完全兼容ABI。此外，标准容器的ABI不兼容性是标准库实现（libstdc ++或libc ++）的属性，而不是编译器的属性。因此，不需要任何重新编译。
如果Clang不能与g ++兼容，那么Clang可能永远不会离开地面，因为如果没有预先存在的大型追随者，它将基本上无法使用。实际上，Clang与GCC是如此兼容，它们实际上几乎都是g ++的命令行界面，编译器内在函数，错误等等，所以你可以直接使用Clang而不是G ++，绝大多数时候，一切都会工作。答案 2 :(得分：2)
这可能无法正确回答确切的问题：
前段时间我尝试用gcc编译一些目标文件，用clang编译另一个目标文件。最后，我将所有内容链接在一起并且工作正常。
我相信Linux发行版使用gcc，因为我检查了一些Ubuntu和CentOS的Makefile，他们使用了gcc。