远程Linux gcc编译std::thread程序触发SIGABRT报错咨询

报错核心触发原因是Linux环境下使用g++编译std::thread相关代码时未添加线程相关编译链接参数，同时代码本身存在两处可移植性问题，按以下步骤修复即可：

1. 补全代码缺失与错误：
   • 补充缺失的头文件：在代码头部添加#include <iostream>，当前代码使用cin/cout却未显式包含该头文件，属于未定义行为。
   • 修正线程ID获取的语法错误：所有调用std::this_thread::get_id的位置末尾补全括号，改为std::this_thread::get_id()，原写法未实际调用函数，只会输出函数地址，无法拿到真实线程ID。
2. 调整编译参数：编译时必须添加-pthread参数，该参数会告知编译器链接POSIX线程库、启用多线程相关的预处理宏，是Linux下编译C++多线程代码的必填参数。标准编译命令示例：

g++ thread_test.cpp -o thread_demo -pthread -std=c++11

修复后重新编译运行即可消除SIGABRT报错。本地Windows端提示的栈帧无法加载错误，是远程程序崩溃后调试器无法匹配崩溃栈帧到源码的连带提示，修复远程端程序崩溃问题后该提示会自动消失。

两边编译器的默认行为差异直接导致了同一份代码本地正常、远程异常的现象，核心差异有三点：

• 线程库链接逻辑不同：Windows端MSVC编译std::thread相关代码时，会自动匹配链接对应多线程版本的C++运行时库，不需要开发者手动添加额外参数；Linux端GCC默认不会主动链接libpthread库，未手动添加-pthread参数时，代码能通过编译但运行时创建线程就会触发std::system_error。
• 头文件依赖策略不同：MSVC的标准库头文件存在较多隐式包含，比如<thread>、<string>头文件会间接引入<iostream>的内容，因此代码未显式包含<iostream>也能正常编译；GCC的标准库头文件依赖边界更清晰，不会无意义引入其他头文件，缺省头文件时容易触发编译错误或未定义行为。
• 调试信息匹配逻辑不同：本地VS调试Windows程序时，调试器可以直接加载本地二进制的调试符号匹配栈帧；远程调试Linux程序时，二进制运行在虚拟机端，若程序异常abort退出，调试器未拿到完整的栈帧符号信息就会弹出栈帧不在已加载模块的提示，属于调试侧的连带反馈，不是代码在Windows端的原生问题。

可以直接在VS项目属性中调整配置，不需要手动登录虚拟机修改编译命令，配置步骤如下：

• 右键项目打开「属性页」，导航到「配置属性 > C/C++ > 命令行」，在「附加选项」中输入-pthread。
• 再导航到「配置属性 > 链接器 > 命令行」，同样在「附加选项」中输入-pthread，保证编译和链接阶段都携带该参数。
• 导航到「配置属性 > 常规」，将「C语言标准」调整为ISO C++11或更高版本（建议C17），避免标准版本不匹配的问题。
• 如果修复编译参数后调试时仍出现栈帧无法加载的提示，导航到「配置属性 > 调试」，确认「调试模式」选择为gdb，且当前编译配置为Debug模式（Debug模式默认会保留调试符号，不会strip二进制）。

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