No such file or directory错误主因是目标板缺失程序声明的动态链接器（如/lib/ld-linux-armhf.so.3），需从交叉工具链sysroot/lib复制对应文件至目标板相同路径，而非修改解释器路径。
找不到动态链接器（ld-linux.so）
交叉编译出的可执行文件在目标板上直接运行时报 bash: ./a.out: No such file or directory，但文件明明存在——这大概率不是路径问题，而是系统找不到匹配的动态链接器。ARM Linux 程序启动时依赖特定架构的 ld-linux-armhf.so.3（或类似名），它通常由工具链提供，但不会自动随程序部署。
- 用
readelf -l a.out | grep interpreter查看程序声明的解释器路径，比如/lib/ld-linux-armhf.so.3 - 检查目标板上该路径是否存在对应文件：
ls /lib/ld-linux-armhf.so.3；若不存在，需从工具链的sysroot/lib目录复制过去 - 不要硬改解释器路径（如用 patchelf），容易破坏 ABI 兼容性；优先保证目标系统有匹配版本的 libc + ld-linux
libc 版本不兼容导致段错误（Segmentation fault）
程序能启动但立刻崩溃，strace ./a.out 显示在 openat(AT_FDCWD, "/lib/libc.so.6", ...) 失败，或 dmesg 提示 “Failed to load library”，说明运行时 libc 版本与编译时 sysroot 不一致。
- 交叉编译时若未指定
--sysroot或CMAKE_SYSROOT，gcc 会默认链接主机上的 libc 头文件和符号，生成的二进制实际依赖高版本 glibc 功能 - 用
readelf -d a.out | grep NEEDED查看依赖项，再用strings /path/to/target/libc.so.6 | grep GLIBC_对比最低要求版本 - 解决方法：编译时显式指定
-Wl,--sysroot=/opt/toolchain/arm-linux-gnueabihf/sysroot，且确保该 sysroot 来自目标板固件或 Buildroot 构建环境
缺少运行时库（libstdc++.so、libgcc_s.so）
程序报错 ./a.out: error while loading shared libraries: libstdc++.so.6: cannot open shared object file，说明目标板没装 C++ 运行时，或版本不对。
- 交叉编译器自带的
libstdc++.so.6和libgcc_s.so.1在工具链的lib或lib64子目录下，不是标准系统路径 - 部署时要么把它们拷到目标板的
/usr/lib，要么用-static-libstdc++ -static-libgcc静态链接（适合小工具，但会增大体积） - 注意：静态链接
libgcc后仍可能需要libatomic，尤其涉及原子操作时，加-latomic并确认目标板有对应库
CMake 工具链配置漏掉 CMAKE_FIND_ROOT_PATH_MODE_*
用 CMake 交叉编译时，第三方库（如 OpenSSL、zlib）被“误抓”了主机系统的 x86_64 版本，导致链接成功但运行失败——这类问题极隐蔽，因为构建阶段完全无提示。
- 必须设置
CMAKE_FIND_ROOT_PATH_MODE_LIBRARY为ONLY，否则find_library()会先搜主机路径 - 验证是否生效：在 CMakeLists.txt 中加
message(STATUS "LIBRARY DIR: ${OPENSSL_LIBRARY}")，确认路径指向工具链 sysroot 而非/usr/lib/x86_64-linux-gnu - 如果项目依赖 pkg-config，还需设置
PKG_CONFIG_SYSROOT_DIR和PKG_CONFIG_PATH指向工具链的lib/pkgconfig
file a.out 确认是 ARM 可执行文件，再用 ldd a.out（在目标板上运行）逐条验证库依赖是否全部满足。 
