通过apt/yum安装的软件包默认使用何种编译器构建？

1. apt/yum仓库库的默认构建编译器 #

• Debian/Ubuntu（apt）：官方仓库的绝大多数软件包使用系统默认版本的gcc编译，比如Ubuntu 22.04对应gcc-11，Debian 12对应gcc-12，发行版的构建流水线默认以gcc作为主力编译器。
• RHEL/CentOS/Fedora（yum/dnf）：同样，官方仓库的库均由系统自带的gcc版本编译，比如RHEL 9使用gcc-11，Fedora 38使用gcc-13。

2. clang编译的主程序能否安全搭配gcc编译的库？ #

绝大多数场景下完全安全，核心原因如下：

• 主流编译器（gcc、clang）遵循统一的ABI标准：比如x86_64平台遵循System V AMD64 ABI，ARM平台遵循对应架构的ABI规范，只要ABI一致，二进制层面的调用不会有问题。
• 发行版库的编译选项保守通用：官方仓库的库会使用兼容主流编译器的通用编译标志，不会启用破坏ABI的激进优化，保障了跨编译器的兼容性。

需注意的少数风险场景 #

• 非标准编译器扩展依赖：如果库中大量使用gcc独有的扩展（如部分__attribute__特性），且你的clang代码直接调用了依赖这些扩展的接口，可能出现兼容性问题，但发行版的通用基础库很少这么做。
• ABI版本不匹配：比如gcc 5前后C++ ABI有过重大变化（如std::string的实现），但只要你的clang版本支持对应ABI（clang 3.5+已支持gcc 5的C++ ABI），且库是用同一ABI版本的gcc编译的，就不会有问题。
• 极端优化选项差异：若库使用了-ffast-math这类改变浮点语义的选项，而主程序未同步开启，可能导致浮点计算结果不一致，但发行版基础库默认不会启用此类选项。

3. 是否需要从源码构建所有依赖？ #

不需要，除非你遇到明确的兼容性问题（如链接错误、运行崩溃、行为异常）：

• 优先尝试调整clang的编译选项：比如指定-stdlib=libstdc++（clang默认会使用系统的libstdc++，也就是gcc配套的标准库），或者用-gcc-toolchain参数对齐库的gcc版本，以此匹配ABI和编译环境。
• 仅当上述方法无效，或你需要自定义依赖的编译参数、功能时，再考虑从源码构建依赖。

内容的提问来源于stack exchange，提问作者Peter