编译GCC native编译器的几点启示

启示

• 编译 GCC native compiler按照官方介绍并不难

步骤见后面实践脚本，以及官方编译指南链接

---

• GCC编译器编译其它程序组件时，会优先使用自身携带的库，例如，常用的自带库，libgcc_s.so、libstdc++

• 如果部署环境与编译要求存在比较大的依赖差异，则会诱发兼容性问题
• 高度推荐容器化部署，使得编译环境与部署环境高度一致
• 组件依赖会形成类似maven库中的依赖树，组件依赖关系各种编程语言均存在类似关系，而这与具体编程语言无关

---

• 在一个环境中使用不同的GCC编译版本，例如，高版本GCC编译器，尽量选择devtooolset-*系列rpm包；但如果devtoolset-*包中对齐的GCC版本并非最后结项版本，则可以选择自行编译GCC native compiler，而这个过程并不难

• 自行编译GCC native compiler，可以参考devtoolset-*系列的目录结构，和其enable切换环境脚本
• devtoolset-*早期版本容易对齐GCC结项版本，后期发行版失去维护后，较新的GCC高版本则一般没有对齐

为什么选择高版本编译器

• 更多的warning、error自动检查

部分warning可以转化成error项，结合静态代码检查工具形成代码开发工具链，以及自动编码规范

• 更准确的错误定位能力，和错误提示
• sanitizer检查能力
• 更优良的代码生成质量
• 新的语言特性

追求新语言特性的优先级最低，除非是必要、能够提高开发效率的语言特性，在一定程度上可以定死编译器的编译标准，作为编码规范的一部分

使用高版本编译器的兼容性问题

图解GCC高版本编译后的部署问题

GCC编译时优先使用自身携带库

• 这些依赖库体现为新的特性，或编译器定制化要求
• 不一致会形成依赖冲突，甚至程序不能运行

推荐部署结构

• 编译环境高度和部署环境一致
• 通过携带少量对齐库依赖，定制环境变量，达到与要求环境模拟一致，但并不污染其它应用
• 忽略差异依赖库的差异，依赖部署环境的向前、向后兼容能力，用覆盖测试进行保证

公之下策，实为上策！

下策看似不推荐，但是其实是大家用的比较多，也比较省事的做法。忽略了差异性可能带来的风险，而由功能覆盖测试保证产品的可用性。