开启-flto编译的C++ std::string程序在RHEL 8段错误 RHEL 7运行正常

是否属于ABI问题 #

是，该问题属于LTO（链接时优化）相关的ABI不兼容问题，和常规C标准库ABI不兼容的区别是，它是编译器LTO中间表示、链接器实现、标准库实现三者的适配冲突导致的，不是基础C语法层面的ABI不匹配。

使用-flto参数时是否需要配置特定路径加载正确的标准库 #

常规原生系统自带的编译器不需要额外配置，但是如果使用自定义安装的GCC版本，需要做两个校验：

1. 编译阶段要保证GCC使用的binutils（ld、ar等工具）版本和GCC版本匹配，不要混用系统自带的低版本binutils
2. 运行阶段要保证程序加载的libstdc++.so是编译时使用的GCC版本对应的库，可通过ldd <可执行文件路径>命令查看动态库加载路径，如果指向系统自带的旧版libstdc++，需要通过LD_LIBRARY_PATH环境变量指定你所用GCC的lib路径后再运行程序。

可能的问题诱因 #

• LTO参数配置不全：你当前仅在编译阶段添加了-flto参数，没有给链接阶段也添加对应-flto参数，CMake中正确配置LTO的方式是设置目标属性INTERPROCEDURAL_OPTIMIZATION ON，由CMake自动处理编译、链接阶段的LTO参数，避免参数不匹配导致的优化逻辑错误。
• binutils版本适配缺陷：RHEL8自带的binutils版本和你使用的GCC10.2的LTO插件存在适配问题，LTO功能要求编译器和链接器版本严格对齐，RHEL7的binutils版本刚好适配该GCC版本的LTO逻辑，RHEL8的版本则存在兼容性问题，优化后生成的二进制存在逻辑错误。
• 标准库版本冲突：运行时程序加载了RHEL8系统自带的、对应GCC8版本的libstdc++.so，和编译时使用的GCC10.2的标准库实现存在差异，LTO优化会把部分标准库内联逻辑编译到目标文件中，和运行时加载的旧版库实现不匹配，触发内存访问错误，std::string::substr刚好是这类问题的高发接口。
• GCC10.2已知LTO缺陷：该版本GCC在RHEL8环境下开启LTO后，对std::string的短字符串优化（SSO）逻辑存在bug，你测试的字符串长度刚好卡在SSO阈值边界，优化后出现指针越界访问，关闭LTO后优化等级降低，不会触发该bug。

内容的提问来源于stack exchange，提问作者Phil-ZXX