确认aarch64-linux-gnu-gcc已就位：运行aarch64-linux-gnu-gcc -v，输出须含"target: aarch64-linux-gnu"及有效版本号；若报command not found，用which aarch64-linux-gnu-gcc检查path，未生效则添加并source或重启终端。
直接用 aarch64-linux-gnu-gcc 或 aarch64-linux-gnu-g++ 替换本地 gcc/g++ 即可开始交叉编译，但必须确保工具链已正确安装、PATH 可见，且不混用宿主机头文件和库——这是绝大多数编译失败的根源。
怎么确认 aarch64-linux-gnu-gcc 已就位
别跳过这步。很多“找不到函数”或“undefined reference”错误，其实只是工具链压根没装好或没生效。
- 运行
aarch64-linux-gnu-gcc -v：输出里必须含Target: aarch64-linux-gnu和有效版本号（如gcc version 12.3.1），而非报command not found - 检查
PATH：用which aarch64-linux-gnu-gcc确认路径，如果返回空，说明没加进环境变量；手动加后要source ~/.bashrc或新开终端 - Ubuntu/Debian 用户注意：装的是
gcc-aarch64-linux-gnu还是带版本号的（如gcc-12-aarch64-linux-gnu）？后者需显式调用aarch64-linux-gnu-gcc-12，否则默认可能仍是系统 gcc
单文件编译时最容易漏的关键参数
只写 aarch64-linux-gnu-g++ -o hello hello.cpp 很可能在目标机上运行崩溃——因为链接了宿主机的 libstdc++.so，而目标 ARM 设备没有对应版本。
- 加
-static-libstdc++：强制静态链接 C++ 标准库，避免目标机缺失动态库 - 加
--sysroot=/path/to/aarch64-rootfs：指定目标系统的根文件系统路径（如从 Yocto 或 Buildroot 导出的sysroot），让编译器只从该路径找头文件（bits/,sys/）和库（libc.so,libm.so），彻底隔绝宿主机干扰 - 不加
--sysroot时，aarch64-linux-gnu-gcc仍会默认搜索自身安装目录下的include和lib，但这些仅含基础头文件，缺linux/、asm/等内核头，也常缺完整 glibc 版本
CMake 项目必须配 toolchain 文件
靠 CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ cmake .. 行不通——CMake 会继续用宿主机的 find_package() 逻辑找库，导致链接错位。
- 写一个
aarch64-toolchain.cmake，核心三行不能少：set(CMAKE_SYSTEM_NAME Linux)、set(CMAKE_SYSTEM_PROCESSOR aarch64)、set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc) -
CMAKE_SYSROOT和CMAKE_FIND_ROOT_PATH必须指向同一sysroot路径，且该路径下要有完整的usr/include和usr/lib -
CMAKE_FIND_ROOT_PATH_MODE_LIBRARY设为ONLY：确保find_library()只在sysroot内找，绝不碰宿主机/usr/lib
为什么编译成功却在目标机上段错误
常见于工具链 glibc 版本高于目标系统。例如工具链基于 glibc 2.38 编译，而树莓派 OS 是 Debian 12（glibc 2.36），运行时就会因符号缺失崩掉。
- 查目标机 glibc 版本：
ldd --version，记下数字（如2.36） - 选工具链时优先匹配：Linaro 官网下载页明确标有
glibc-2.36的包，比最新版更稳妥 - 若必须用新版工具链，编译时加
-D_GLIBCXX_USE_C99=0等兼容性宏，或降级链接时的--dynamic-list-data参数（极少需手动干预）
真正麻烦的不是装工具链，而是让整个构建过程严格区分“宿主机视角”和“目标机视角”——所有路径、头文件、库、甚至 sizeof(long) 的结果，都得按 AArch64 的规则来算，一步错，全盘错。
