Linux GCC静态编译C++程序抛出任意异常即终止问题求助

• 符号覆盖问题
  静态链接时，用户自定义目标文件的符号优先级高于系统静态库的符号。如果misc.cpp中意外定义了任何C++异常处理核心函数的同名符号（包括弱符号），就会覆盖libstdc++的默认实现，导致异常抛出流程异常。
  常见的冲突符号包括：__cxa_throw、__gxx_personality_v0、_Unwind_RaiseException等异常处理底层函数，哪怕你没有主动调用这些函数，只要misc.cpp参与链接，就会替换系统实现。
• 全局异常处理配置被修改
  C++允许通过std::set_terminate、std::set_unexpected全局修改异常处理回调。如果misc.cpp中定义了全局/静态对象，对象的构造函数在main函数执行前就已经调用了上述接口修改了全局配置，哪怕整个程序没有调用misc.cpp的任何业务逻辑，修改后的配置也会生效，导致异常抛出后直接触发terminate。
• 编译选项不匹配
  如果misc.cpp的编译参数和其他编译单元不一致，也会导致异常处理逻辑损坏：
  1. 给misc.cpp单独加了-fno-exceptions参数：关闭异常的编译单元会缺失异常栈展开所需的元数据，静态链接后全局异常处理流程会被破坏
  2. 给misc.cpp单独加了-fno-rtti参数：异常类型匹配依赖RTTI信息，缺失RTTI会导致抛出的异常无法和catch块的类型匹配，被判定为无匹配catch块直接调用terminate
  3. 符号可见性配置错误：如果misc.cpp加了-fvisibility=hidden且没有显式导出异常相关的类型信息，会导致跨编译单元的异常类型识别失败。
• 类型信息冲突
  如果misc.cpp中定义了和标准库同名的类型（比如自定义了std::runtime_error或者std::exception的同名实现），静态链接时会出现类型信息冲突，导致catch块无法正确匹配抛出的异常类型。

1. 对比misc.cpp和正常的throw.cpp的编译参数，确认没有-fno-exceptions、-fno-rtti、异常的符号可见性参数的差异
2. 全局搜索misc.cpp中是否有调用std::set_terminate、std::set_unexpected的代码，尤其是全局对象构造函数中的调用
3. 用nm misc.o命令查看misc.o的导出符号，搜索是否存在__cxa_*、__gxx_personality_v0、_Unwind_*这类异常处理相关的符号定义，如果存在则说明出现了符号覆盖
4. 检查misc.cpp中是否有自定义的标准库同名类型、异常类型，是否存在异常类的对齐、属性配置错误

你当前的链接命令存在一个不规范的地方：静态链接依赖pthread时，建议在编译和链接参数都加上-pthread，而不是只加-lpthread，否则可能出现多线程场景下的异常处理、线程局部存储相关的隐性问题。

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