C++17、LTO与-static-libstdc++问题：ld.gold重定位警告及段错误

这问题确实棘手——没法做最小复现的话，排查起来得靠一些针对性的调试技巧，结合你给出的编译参数（尤其是LTO、gold链接器、静态标准库这些关键配置），我整理几个实用的方向你试试：

1. 深挖链接警告的根源 #

那个Warning: relocation refers to discarded section警告绝对是关键线索，别因为是warning就忽略它。可以给链接器加这些参数放大输出：

• 加-Wl,--warn-unresolved-symbols：强制链接器报告未解析的符号，说不定能找到和被丢弃段相关的关联符号
• 加-Wl,--verbose：输出详细的段处理、符号链接过程，定位到底是哪个重定位指向了被丢弃的段
• 临时关闭LTO分区优化：加-flto-partition=none，看看是不是LTO的并行分区导致某些段被误判为无用代码而丢弃

2. 用GDB定位__run_exit_handlers的具体错误点 #

__run_exit_handlers是glibc执行退出处理函数的入口，段错误大概率是某个注册的退出函数指针失效，或者对应的代码段被丢弃了：

• 启动GDB后先设置断点：b __run_exit_handlers，运行程序触发断点后，用x/i $pc查看当前执行的指令，用info registers看寄存器状态，确定是访问了无效地址还是执行了非法指令
• 查看所有注册的退出处理函数：用info functions __cxa_atexit，然后对每个函数地址执行info symbol <地址>，检查该函数是否存在于有效段中
• 尝试强制链接所有符号：给相关库（尤其是自定义库和Boost）加上-Wl,--whole-archive参数，避免链接器把注册了退出处理的函数当成无用代码丢弃——LTO的-O3优化很容易干这种“过火”的事

3. 逐步调整编译参数缩小范围 #

通过增减参数来定位问题根源：

• 先去掉-flto=10和-fuse-linker-plugin，如果问题消失，那就是LTO和gold链接器的交互bug。可以尝试降低LTO并行数（比如-flto=4），或者升级binutils到2.32+版本——旧版gold对LTO的支持确实存在一些已知问题
• 把-O3换成-O2，验证是不是O3的激进优化导致代码/段被错误丢弃
• 保留-static-libstdc++ -static-libgcc但切换为动态链接，看看是不是静态链接场景下的特殊问题

4. 验证Boost库的编译一致性 #

你提到Boost用了相同参数编译，但要仔细确认：

• 所有Boost组件是不是都严格用了-fno-PIC、-flto、-std=c++1z这些参数？比如Boost.Thread、Boost.Filesystem这类带内部初始化/退出逻辑的组件，有没有可能编译时漏加了LTO？
• 重新编译Boost时，明确指定cxxflags和linkflags：

  ./b2 cxxflags="-flto=10 -fno-PIC -std=c++1z -O3 -UNDEBUG" linkflags="-flto=10 -fuse-ld=gold -lrt -ldl"
  

  确保和主程序的编译链接参数完全对齐

5. 排查glibc兼容性问题 #

旧版glibc和gcc-7.3.0的LTO静态链接可能存在兼容性问题：

• 检查系统glibc版本，如果低于2.27，尝试升级到较新版本
• 可以尝试添加临时链接补丁：-Wl,--defsym=__libc_csu_fini=__libc_csu_fini_real，部分场景下能规避__run_exit_handlers的段错误问题

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