“undefined reference to xxx”是链接阶段库缺失的典型信号，表明链接器无法解析函数符号，需检查是否添加-lxxx、-l路径是否正确、依赖顺序是否合理，并区分编译主机与目标设备的库环境。

交叉编译时提示“undefined reference to xxx”

这是链接阶段最典型的库缺失信号，不是头文件没找到，而是函数符号在链接时无法解析。常见于调用 OpenSSL、zlib、pthread 等外部库的代码。

关键判断点：错误里出现 undefined reference，而非 No such file or directory —— 前者是链接问题，后者才是头文件或源文件路径问题。

• 先确认你是否在链接命令中加了 -lxxx（比如 -lcrypto），且拼写与实际库名一致（libcrypto.so → -lcrypto）
• 用 arm-linux-gnueabihf-gcc -print-search-dirs 查看工具链默认的库搜索路径，检查目标库（如 libcrypto.a）是否真在其中
• 如果库在非标准位置（例如 /opt/sysroot/usr/lib），必须显式加 -L/opt/sysroot/usr/lib，且 -L 要放在 -lxxx 之前
• 静态链接时注意依赖顺序：gcc main.o -lcrypto -lz 可能失败，而 gcc main.o -lz -lcrypto 成功——因为链接器从左到右解析，后出现的库可满足前一个库的未定义符号

运行时提示“cannot open shared object file: libxxx.so: No such file or directory”

编译通过了，但板子上跑不起来。这和编译主机无关，是目标设备的动态链接器找不到库。

根本原因：交叉编译生成的可执行文件或 so 文件，其 DT_RUNPATH 或 DT_RPATH 字段为空，或指向了板子上不存在的路径（比如 /usr/lib），而板子实际只挂载了 /lib。

GCC 14.1

GCC 14.1 官方历史源码包下载入口，适合旧项目兼容、编译环境回退、工具链验证、警告参数差异比对和 C/C++ 构建问题复现等场景使用。

下载

• 不要直接改板子的 LD_LIBRARY_PATH（很多嵌入式系统不支持或被禁用），优先用 patchelf 重写 rpath：patchelf --set-rpath '/lib:/usr/lib' your_binary
• 若用 CMake，加这两行确保生成的二进制自带 rpath：set(CMAKE_INSTALL_RPATH "$ORIGIN/../lib;$ORIGIN/lib") 和 set(CMAKE_BUILD_RPATH_USE_ORIGIN ON)
• 检查板子上是否存在对应库：adb shell ls /lib/libc.so.6 或 readelf -d your_binary | grep RUNPATH
• 特别注意 libc 版本兼容性：用 file your_binary 看它依赖的是 libc.so.6 还是 libc.musl，别把 glibc 编译的程序扔到 musl 根文件系统上

交叉编译工具链自身缺库，比如找不到 libstdc++.so.6

现象是编译命令刚执行就报错：arm-linux-gnueabihf-g++: error while loading shared libraries: libstdc++.so.6: cannot open shared object file。

这不是你的项目缺库，而是交叉编译器运行时缺依赖 —— 它自己是个 x86_64 程序，却链接了目标平台的 C++ 库（错误！）。

• 立刻检查 arm-linux-gnueabihf-g++ 的依赖：ldd $(which arm-linux-gnueabihf-g++)，如果输出里有 libstdc++.so.6 => not found，说明宿主机缺对应版本的 libstdc++
• Ubuntu/Debian 上装 libstdc++6 即可；CentOS/RHEL 装 libstdc++-devel 或对应版本的 libstdc++ 包
• 切勿把目标平台的 libstdc++.so.6（aarch64 架构）拷到宿主机 —— 宿主机 loader 无法加载它
• 某些精简版工具链（如 Buildroot 生成的）会静态链接自身依赖，避免此问题；若你用的是 Linaro 工具链，确认下载的是 x86_64 host 版本，不是 aarch64 host 版本

find_package 在 CMake 中找不到第三方库

CMake 报 Could not find xxx，但你知道库就在 /opt/opencv-arm 下 —— 这是因为 CMake 默认只查系统路径和 CMAKE_PREFIX_PATH，不自动扫描任意目录。

别急着改 link_directories()，那是过时做法，且对 find_package() 无效。

• 最稳妥方式：用 -DCMAKE_PREFIX_PATH=/opt/opencv-arm 传给 cmake 命令，CMake 会去 /opt/opencv-arm/lib/cmake/opencv4/ 这类路径找 config 文件
• 如果库没提供 *Config.cmake，而只有 .so 和 .h，改用 find_library(OpenCV_LIBS NAMES opencv_core PATHS /opt/opencv-arm/lib)
• 验证路径是否生效：message(STATUS "CMAKE_PREFIX_PATH = ${CMAKE_PREFIX_PATH}")，确保变量值是你预期的
• 注意大小写：某些工具链打包时把 OpenCVConfig.cmake 写成 opencvConfig.cmake，find_package(OpenCV) 就会失败，得换成 find_package(opencv)

真正卡住人的地方，往往不是“该加哪个 -L”，而是搞不清当前问题发生在哪个环节：是编译器找头文件、链接器找库、还是目标设备的动态链接器找库。每一步的路径来源完全不同，混用 LD_LIBRARY_PATH、LIBRARY_PATH、-L、rpath 会导致问题层层叠加。