c++oding="utf-8" ?>
C++在嵌入式Linux上运行完全可行，但需禁用异常（-fno-exceptions）、RTTI（-fno-rtti），静态链接libgcc，避免依赖裁剪后的libstdc++；undefined reference to __cxa_begin_catch即因启用了异常但目标系统缺失对应运行时支持。
直接说结论：C++在嵌入式Linux上运行完全可行，但不能照搬桌面开发那一套——关键在于禁用不安全特性、链接正确运行时、避免依赖未裁剪的glibc++。
为什么编译通过却运行失败：undefined reference to `__cxa_begin_catch'
这是最典型的链接错误，说明你启用了C++异常（默认开启），但目标系统没提供libstdc++的异常支持部分。嵌入式Linux根文件系统通常精简过，libstdc++.so被裁剪或压根没装。
- 编译时必须加
-fno-exceptions -fno-rtti，彻底关掉异常和运行时类型信息 - 链接时显式指定最小运行时：
-static-libgcc -lgcc，避免动态依赖libstdc++ - 如果坚持用
libstdc++，得确认根文件系统里有对应版本的libstdc++.so.6，且ldd能解析到
main函数之前就崩了：全局对象构造失败
嵌入式Linux启动阶段没有完整的C++运行时初始化流程，__libc_start_main调用__do_global_ctors可能出错，尤其当全局对象构造函数里调用了malloc或std::cout这类依赖完整库的函数。
- 所有全局对象的构造函数必须是
noexcept，且只做纯C式操作（如寄存器赋值、数组初始化） - 禁用
-fno-common以外的全局符号优化，防止链接器合并符号时破坏初始化顺序 - 更稳妥的做法：把初始化逻辑移到
main()里，用静态局部变量替代全局对象
用户空间驱动怎么写才不踩坑
别碰内核模块里的C++——Linux内核不认new、delete、虚函数表。但在用户空间封装设备操作，C++反而是优势。
- 用RAII管理
fd、mmap地址、pthread_mutex_t等资源，比C语言手动close/munmap可靠得多 - 类成员函数必须声明为
noexcept，尤其是析构函数——否则异常抛出到C上下文会直接abort() - 避免
std::string和std::vector：它们隐式调用malloc，而嵌入式Linux的堆可能极小或不可靠；改用固定大小缓冲区或std::array
交叉编译链和CMake怎么配才稳
用arm-linux-gnueabihf-g++这类工具链时，CMake默认仍会查宿主机的libstdc++路径，导致链接错位。
- CMakeLists.txt里必须设置：
set(CMAKE_CXX_STANDARD 17)+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-exceptions -fno-rtti") - 强制指定sysroot：
set(CMAKE_SYSROOT "/path/to/sysroot")，否则#include <vector></vector>可能混进桌面头文件 - 检查最终生成的可执行文件：
file a.out确认是ARM ELF，readelf -d a.out | grep NEEDED确认只依赖libc.so.6和libgcc_s.so.1（如果用了-shared-libgcc）
真正容易被忽略的是：嵌入式Linux的/lib目录下ld-linux-armhf.so.3版本必须和交叉工具链匹配，差一个小版本都可能卡在动态链接器入口。上线前务必在目标板上跑strace ./a.out看第一行加载了哪个解释器。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
