ARM-Linux交叉编译工具链安装与Qt/Boost/chrony避坑指南

ARM-Linux 交叉编译工具链安装这件事，说简单也简单，apt 一条命令就能把 gcc-arm 拉下来；说麻烦也麻烦，真到 Qt、Boost、chrony 这些依赖上，工具链选错一个 ABI，后面全是坑。我这几年前后在 x86 笔记本、Ubuntu 20.04/24.04、几块 ARM 板子上来回折腾，最深的感受是：装工具链本身十分钟，难的是把工具链、sysroot、目标板系统三者对齐。这篇就把我实际用的安装流程、验证方法、参数拆解和踩坑记录整理出来，适合刚接触 ARM-Linux 交叉编译工具链的嵌入式新手，也适合正在给 Orange Pi CM5、RK3588 这类板子搭 Qt5 交叉编译环境的老手复盘。文中会涉及 arm-linux-gnueabihf、aarch64-linux-gnu、arm-none-eabi 的选型差异，也会把 qt5.12.10 交叉编译、qt-everywhere-src-5.15.10 交叉编译、Boost 库交叉编译、chrony 交叉编译这些热搜场景串起来讲清楚。

1. 先搞清楚目标：ARM-Linux 交叉编译工具链到底解决什么问题

很多人第一次听到“交叉编译”会有点懵：我明明在 Ubuntu 上敲 gcc，为什么还要装一个 gcc-arm 工具链？原因很直接，你手上的开发机大概率是 x86_64 架构，而目标板是 ARM 架构。x86 上的 gcc 生成的是 x86 指令，放到 ARM 板子上根本跑不起来。交叉编译工具链干的事，就是在 x86 宿主机上运行编译器，但生成 ARM 目标平台能执行的二进制程序。

1.1 为什么还要用 gcc-arm 工具链交叉编译

有人会问，Orange Pi CM5、树莓派这类板子性能已经不差了，直接在上面装 gcc 编译不行吗？行，但体验和效率是两码事。第一，板子上的 CPU 和内存资源通常不如开发机，编译 Qt 这种大项目可能要几个小时甚至更久，x86 开发机可能二十分钟就完事。第二，板子上的系统往往是最小化 rootfs，缺 Python、缺 CMake、缺各种开发头文件，补依赖本身就是个无底洞。第三，交叉编译环境更容易做成可复用的 Docker 镜像或脚本，CI 流水线里也能固定版本，不会因为板子系统升级导致编译结果飘忽。

但交叉编译不是没有代价。你需要在宿主机上准备目标板的 sysroot，也就是目标板的头文件和库集合。很多新手只装了 gcc-arm 工具链，编译一个 hello 程序没问题，一旦链接 OpenSSL、Qt、Boost 就报找不到库。根本原因是工具链自带的 sysroot 只包含基础 glibc，不包含目标板上额外的第三方库。所以，交叉编译工具链安装只是第一步，真正的功夫在 sysroot 准备和依赖库交叉编译上。

1.2 工具链命名规则与选型对照

ARM 工具链命名看着乱，其实有规律。以aarch64-linux-gnu-gcc为例，aarch64表示目标 CPU 架构是 ARM64，linux表示目标操作系统是 Linux，gnu表示使用 GNU C 库，也就是 glibc。如果是arm-linux-gnueabihf，arm表示 32 位 ARM，eabi表示嵌入式 ABI，hf表示硬浮点。选错前缀，编译出来的程序上板子要么直接无法执行，要么链接阶段就报 ABI 不兼容。

Orange Pi CM5 用的是 RK3588S，系统通常是 ARM64，所以热搜里“orangepi cm5安装qt5 交叉编译”这个场景，应该用aarch64-linux-gnu工具链，而不是 32 位的arm-linux-gnueabihf。我见过有人拿 32 位工具链去编译 CM5 的 Qt，折腾一天最后发现架构都不对，这个坑完全可以在选型阶段避开。

1.3 宿主机环境规划：Ubuntu 20.04、24.04 与虚拟机架构选择

宿主机选 Ubuntu 20.04 还是 24.04，主要看你要编译的代码有多老。20.04 的 GCC 9 和 glibc 2.31 对老项目更友好，很多厂商 SDK 也是在这个版本上验证的。24.04 默认 GCC 13、glibc 2.39，编译新项目更舒服，但遇到老 Qt 或老内核模块，可能会因为-Werror、隐式函数声明、std::filesystem链接顺序等报错。我的习惯是主机用 Ubuntu 24.04，交叉编译环境用 Docker 跑 Ubuntu 20.04 容器，这样两边的优点都占。

虚拟机方面，如果你在 x86 主机上用 VMware 装 Ubuntu，通常选 x86_64 架构就行，不要纠结“vmware安装ubuntu虚拟机选择arm架构”这个说法。x86 主机上的 VMware 一般跑的是 x86_64 客户机，交叉编译工具链本身也是 x86_64 主机程序，只是生成 ARM 目标代码。真正需要 ARM 架构虚拟机的是 Apple Silicon 上的 VMware Fusion，或者你想做 native 编译验证。给交叉编译虚拟机分配建议：至少 4 核 CPU、8GB 内存、100GB 磁盘，编译 Qt 时 8 核 16GB 会舒服很多。

2. 安装实操：apt 包管理器与手动解压两条路

ARM-Linux 交叉编译工具链的安装，常见就两条路：一条是 Ubuntu apt 直接装，适合快速起步；另一条是下载官方 GNU 工具链压缩包手动解压，适合需要固定版本、目标板 SDK 指定版本、或者 Ubuntu 源里版本太老的情况。两条路没有绝对好坏，关键看你的项目是否要求工具链版本和厂商 BSP 一致。

2.1 apt 安装交叉工具链：最快但要注意版本

在 Ubuntu 20.04/24.04 上，如果要装 ARM64 交叉工具链，可以这样：

sudo apt update sudo apt install -y gcc-aarch64-linux-gnu g++-aarch64-linux-gnu binutils-aarch64-linux-gnu

如果要装 32 位 ARM 硬浮点工具链，则：

sudo apt install -y gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf binutils-arm-linux-gnueabihf

装完先别急着编译项目，先用aarch64-linux-gnu-gcc -v看一眼版本。apt 安装的好处是依赖自动解决，和 Ubuntu 源里的交叉库如libc6-dev-arm64-cross能对上。缺点是版本跟着 Ubuntu 走，20.04 上可能是 GCC 9，24.04 上可能是 GCC 13。如果你编译的目标板 glibc 比较老，用新工具链编译出来的程序可能提示GLIBC_2.xx not found。这时候要么降工具链，要么用目标板 sysroot，要么静态链接，但静态链接对 Qt 这类库几乎不现实。

还有一个细节：apt 里的交叉工具链包名和命令前缀不一定完全一致。比如gcc-aarch64-linux-gnu安装后命令是aarch64-linux-gnu-gcc，g++-aarch64-linux-gnu安装后是aarch64-linux-gnu-g++。如果你只装了 gcc 没装 g++，编译 C++ 项目时会报找不到aarch64-linux-gnu-g++，这时候补装 g++ 交叉包即可。

2.2 手动安装官方 GNU 工具链：适合老系统与固定版本

当项目要求固定 GCC 版本，或者目标板厂商给了指定工具链，就用手动解压。以 ARM64 官方 GNU 工具链为例，下载gcc-arm-*.tar.xz后，可以放到/opt/toolchains：

sudo mkdir -p /opt/toolchains sudo tar -xf gcc-arm-*.tar.xz -C /opt/toolchains

解压后会得到一个类似gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu的目录。里面的bin下就有aarch64-none-linux-gnu-gcc。注意，不同官方工具链的前缀可能是aarch64-none-linux-gnu，不一定和 apt 的aarch64-linux-gnu一样。编译时可以用CROSS_COMPILE变量统一，但前提是项目 Makefile 支持。

如果不想污染系统目录，也可以解压到$HOME/toolchains。我一般推荐个人目录，尤其是公司电脑多用户环境，避免 sudo 权限问题。把工具链路径加入 PATH 后，用which aarch64-none-linux-gnu-gcc确认。手动工具链的好处是自带完整 sysroot，版本可控；坏处是如果和目标板 glibc 版本差异大，同样会遇到运行时报错。

2.3 PATH、CROSS_COMPILE 与多版本共存管理

交叉编译环境变量最常配这几个：

export CROSS_COMPILE=aarch64-linux-gnu- export ARCH=arm64 export PATH=/opt/toolchains/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin:$PATH

CROSS_COMPILE在内核和 U-Boot 编译里很常见，ARCH指定目标架构。注意 PATH 顺序，如果你同时装了 apt 工具链和手动工具链，谁在前面就用谁。可以用which -a aarch64-linux-gnu-gcc查看所有同名命令。多版本共存时，我建议写一个env.sh：

#!/bin/bash export TOOLCHAIN_ROOT=/opt/toolchains/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu export PATH=$TOOLCHAIN_ROOT/bin:$PATH export CROSS_COMPILE=aarch64-none-linux-gnu- export ARCH=arm64 export SYSROOT=/opt/sysroot/cm5

每次开终端source env.sh，比全局写进/etc/profile干净得多。项目之间切换工具链版本时，也不会互相打架。

3. 验证工具链：从 hello 程序到 ABI 检查

工具链装完一定要验证，不能直接上大项目。验证分三层：第一层确认工具链能运行，第二层确认生成的 ELF 是 ARM 架构，第三层确认程序能在目标板或模拟环境里跑起来。很多“工具链安装成功但编译失败”的问题，都是跳过了验证直接上 Qt，结果报错信息被淹没在几千行日志里。

3.1 工具链自检与目标三元组确认

先看目标三元组：

aarch64-linux-gnu-gcc -dumpmachine

正常输出类似aarch64-linux-gnu。再看版本和配置：

aarch64-linux-gnu-gcc -v

输出里会显示Target: aarch64-linux-gnu、Configured with:、Thread model:等信息。如果你用的是arm-linux-gnueabihf-gcc，Target应该显示arm-linux-gnueabihf。这一步能快速发现是否装错包，比如想装 64 位却装了 32 位。

还可以看默认 sysroot：

aarch64-linux-gnu-gcc --print-sysroot

如果输出为空，说明工具链使用内置相对路径 sysroot；如果输出/opt/sysroot，说明配置了外部 sysroot。交叉编译 Qt 时，这个值很关键，因为头文件和库都从这里找。

3.2 编译第一个 ARM-Linux 程序并检查 ELF

写一个最小hello.c：

#include <stdio.h> int main(void) { printf("hello arm-linux\n"); return 0; }

交叉编译：

aarch64-linux-gnu-gcc hello.c -o hello file hello

file输出应该包含ELF 64-bit LSB executable, ARM aarch64。如果显示x86-64，说明你用成了宿主 gcc。接着看 ELF 头：

aarch64-linux-gnu-readelf -h hello

重点看Machine: AArch64、Class: ELF64、Type: DYN或EXEC。再看 ABI 信息：

aarch64-linux-gnu-readelf -A hello

如果是 32 位 ARM 硬浮点，会看到Tag_ABI_VFP_args: VFP registers。有些板子报Illegal instruction，就是浮点 ABI 或 CPU 指令集不匹配，比如给 ARMv7 板子编译了 ARMv8 指令。

3.3 动态链接器、sysroot 与目标板运行验证

动态链接程序还需要看解释器路径：

aarch64-linux-gnu-readelf -l hello | grep interpreter

ARM64 通常输出/lib/ld-linux-aarch64.so.1，32 位 ARM 硬浮点通常是/lib/ld-linux-armhf.so.3。如果这个路径在目标板上不存在，运行时会报No such file or directory，而且这个报错很容易被误认为程序不存在。把hello拷到板子上执行：

scp hello root@192.168.1.100:/tmp/ ssh root@192.168.1.100 /tmp/hello

如果没有板子，可以用 qemu-user 模拟：

sudo apt install qemu-user-static qemu-aarch64-static -L /opt/sysroot/cm5 ./hello

-L指向目标板 sysroot。没有 sysroot 时，QEMU 找不到动态库，会报Could not open '/lib/ld-linux-aarch64.so.1'。准备 sysroot 最简单的方法是从板子上 rsync：

mkdir -p /opt/sysroot/cm5 rsync -avz root@192.168.1.100:/lib/ /opt/sysroot/cm5/lib/ rsync -avz root@192.168.1.100:/usr/include/ /opt/sysroot/cm5/usr/include/ rsync -avz root@192.168.1.100:/usr/lib/ /opt/sysroot/cm5/usr/lib/

注意 rsync 时保留符号链接，不要用-L把链接全展开成实体文件，否则 sysroot 会膨胀且容易冲突。更推荐直接用板子厂商 SDK 或 Yocto SDK 里的 sysroot，比手工 rsync 干净。

4. 进阶依赖：Qt、Boost、chrony 等库的交叉编译思路

工具链验证通过后，真正的项目依赖才开始。Qt、Boost、chrony 这些库各有各的构建系统，交叉编译参数也不一样。核心逻辑是一样的：指定交叉编译器、指定 sysroot、指定目标平台、禁用不需要的模块。下面按实际场景拆开讲。

4.1 Orange Pi CM5 安装 Qt5 交叉编译环境的关键准备

Orange Pi CM5 是 ARM64 平台，装 Qt5 交叉编译环境前，先确认板子系统架构：

uname -m

如果是aarch64，就用aarch64-linux-gnu工具链。接着准备 sysroot，最好从板子或官方 Ubuntu rootfs 拉取。Qt 需要的基础依赖包括：libfontconfig1-dev、libfreetype6-dev、libx11-dev、libxext-dev、libxrender-dev、libegl1-mesa-dev、libgles2-mesa-dev、libinput-dev、libts-dev等。注意这些库必须也是 ARM64 版本，不能直接拿宿主 x86 的 dev 包。

如果你的板子跑的是带桌面的 Ubuntu，可以直接 rsync 完整 rootfs。如果跑的是最小系统，可能没有 X11，Qt 就得走linuxfb或eglfs。我一般先在板子上apt install好 Qt 运行时依赖，再从板上拉 sysroot，这样库版本最匹配。编译 Qt 的宿主机还需要ninja-build、python3、perl、bison、flex、gperf等工具，这些是宿主工具，用 apt 装 x86 版本即可。

4.2 qt-everywhere-src-5.15.10 与 qt5.12.10 配置参数拆解

Qt 交叉编译最关键是 mkspecs 和 configure 参数。以 qt-everywhere-src-5.15.10 交叉编译为例，先创建 mkspecs 目录：

cd qt-everywhere-src-5.15.10 mkdir -p qtbase/mkspecs/linux-aarch64-gnu-g++

编辑qtbase/mkspecs/linux-aarch64-gnu-g++/qmake.conf：

MAKEFILE_GENERATOR = UNIX CONFIG += incremental QMAKE_INCREMENTAL_STYLE = sublib include(../common/linux.conf) include(../common/gcc-base-unix.conf) include(../common/g++-unix.conf) QT_QPA_DEFAULT_PLATFORM = linuxfb QMAKE_CC = aarch64-linux-gnu-gcc QMAKE_CXX = aarch64-linux-gnu-g++ QMAKE_LINK = aarch64-linux-gnu-g++ QMAKE_AR = aarch64-linux-gnu-ar cqs QMAKE_OBJCOPY = aarch64-linux-gnu-objcopy QMAKE_STRIP = aarch64-linux-gnu-strip load(qt_config)

然后 configure：

./configure -prefix /opt/qt5.15.10-arm64 \ -opensource -confirm-license -release \ -xplatform linux-aarch64-gnu-g++ \ -sysroot /opt/sysroot/cm5 \ -no-opengl -linuxfb \ -nomake examples -nomake tests \ -skip qtwebengine

参数解释：-xplatform指定目标 mkspec，-sysroot指向目标板根文件系统，-no-opengl在没有 GPU 加速时减少依赖，-linuxfb指定默认 QPA 平台，-skip qtwebengine跳过 QtWebEngine，这个东西交叉编译极其麻烦，体积也大。qt5.12.10 交叉编译参数类似，但 5.12 对 Python 和 Ninja 要求不同，部分模块名也有差异。如果你用 qt5.12.10，建议先./configure -help看当前版本支持的参数，不要直接照搬 5.15 的。

编译：

make -j$(nproc) make install

安装后，用生成的qmake编译一个小 Qt 程序，检查是否生成 ARM64 ELF。注意不要误用宿主机的 qmake，which qmake一定要指向/opt/qt5.15.10-arm64/bin/qmake。

4.3 Boost 库交叉编译：b2、toolset 和 sysroot

Boost 库交叉编译的核心是告诉 b2 使用交叉编译器，并且把 sysroot 传给编译和链接。先解压 Boost，执行：

./bootstrap.sh --prefix=/opt/boost-arm64

然后编辑生成的project-config.jam，加入：

using gcc : arm64 : aarch64-linux-gnu-g++ ;

这里arm64是自定义 toolset 名称，后面 b2 要用toolset=gcc-arm64。编译命令：

./b2 -j8 toolset=gcc-arm64 target-os=linux architecture=arm address-model=64 \ --prefix=/opt/boost-arm64 --layout=system \ link=static runtime-link=shared \ --with-system --with-filesystem --with-thread \ cxxflags="--sysroot=/opt/sysroot/cm5" \ linkflags="--sysroot=/opt/sysroot/cm5"

实际使用中，architecture=arm加address-model=64表示 ARM64。如果目标板是 32 位 ARM，则architecture=arm address-model=32。--layout=system生成不带编译器版本后缀的库名，链接时更方便。Boost 在交叉编译时，b2 会用宿主 g++ 编译一些构建工具，这是正常现象，不要看到宿主 gcc 就以为配置错了。

常见坑：一是project-config.jam里的 toolset 名称和命令行不一致，导致 b2 回退到默认 gcc，生成 x86 库；二是 sysroot 只加在cxxflags没加linkflags，编译能过链接报错；三是需要-fPIC时忘了加cxxflags=-fPIC，动态库链接失败。

4.4 chrony 等 autotools 项目交叉编译要点

chrony 是典型的 Autotools 项目，交叉编译时关键是--host：

./configure --host=aarch64-linux-gnu \ --prefix=/usr \ --sysconfdir=/etc \ --localstatedir=/var \ --disable-seccomp \ --disable-libcap \ --without-nettle \ CC=aarch64-linux-gnu-gcc \ CFLAGS="--sysroot=/opt/sysroot/cm5 -O2" \ LDFLAGS="--sysroot=/opt/sysroot/cm5"

--host会告诉 configure 这是交叉编译，避免它尝试运行测试程序。--disable-seccomp和--disable-libcap是为了减少目标板额外依赖，如果目标系统确实需要这两个特性，再打开并提前交叉编译对应库。--without-nettle是禁用 Nettle 加密库，如果你的 chrony 需要 NTS 再另行处理。

编译后不要直接make install到宿主机根目录，用DESTDIR安装到临时目录：

make -j8 make DESTDIR=/tmp/chrony-arm64 install

然后把/tmp/chrony-arm64下的文件打包进目标板 rootfs。chrony 交叉编译常见问题是 configure 阶段找不到librt，可以在LIBS里加-lrt；还有就是目标板内核版本太老，adjtimex相关结构体不一致，这种情况只能换工具链或打补丁。

5. 特殊场景：AUTOSAR、ETAS 工具链与 STM32 开发要不要 arm-gcc

交叉编译工具链不是只有 Linux 应用这一种用法。汽车电子里的 AUTOSAR、ETAS 工具链，单片机里的 STM32 开发，都和通用 gcc-arm 有关系，但边界要分清楚，否则容易在项目选型时走弯路。

5.1 AUTOSAR/ETAS 工具链和通用 gcc-arm 的边界

AUTOSAR 自适应平台基于 POSIX，底层通常跑 Linux，所以理论上可以用 aarch64-linux-gnu 或 arm-linux-gnueabihf 交叉编译。但实际项目里，ETAS 这类商业工具链往往有自己的编译器、链接脚本、内存布局配置和许可证管理。通用 gcc-arm 可以用来做原型验证、单元测试，但不能随便替换量产工具链，因为功能安全认证、代码生成配置、MCU 抽象层都绑定在特定工具链上。

我的建议是：如果你只是想在开发板上跑一个 AUTOSAR 自适应应用做验证，用 Yocto SDK 里的交叉工具链就够了；如果是量产项目，严格按项目指定工具链走，不要因为 apt 安装方便就换。工具链版本、编译选项、优化等级都可能影响功能安全认证结果。

5.2 STM32 开发需要安装 arm-gcc 交叉编译链吗

这个问题热搜里也出现了：“stm开发需要安装 arm-gcc‘交叉编译链吗”。答案要看你开发的是哪类 STM32。如果是 STM32F1、STM32F4、STM32H7 这类裸机或 RTOS 项目，用的是arm-none-eabi-gcc，不是arm-linux-gnueabihf。arm-none-eabi面向裸机，没有 Linux 系统调用，链接的是 newlib 或 newlib-nano，不是 glibc。

如果你用 STM32CubeIDE，它自带arm-none-eabi-gcc，不需要你单独 apt 安装。如果你用命令行 Makefile 或 CMake，可以装：

sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi

如果是 STM32MP1 这类跑 Linux 的 MPU，才需要arm-linux-gnueabihf或aarch64-linux-gnu。所以“STM32 开发要不要 arm-gcc 交叉编译链”这个问题，先确认是 MCU 裸机还是 MPU Linux，再选arm-none-eabi还是arm-linux前缀。

5.3 国产 ARM 板卡与 Ubuntu 24.04 交叉编译的适配

Ubuntu 24.04 交叉编译 arm 的体验整体比 20.04 好，工具链新、CMake 新、Python 新，但老项目会碰到一些兼容问题。比如老版本 Qt 的configure脚本可能把 GCC 13 的警告当错误，导致-Werror失败；老内核模块可能因为-fno-common默认开启而报重复符号。遇到这类问题，优先在编译参数里加-Wno-error，或者在 Docker 里用 Ubuntu 20.04 编译。

另一个常见问题是 32 位交叉工具链在 64 位 Ubuntu 24.04 上的依赖。某些厂商工具链是 32 位 x86 主机程序，需要安装 i386 库：

sudo dpkg --add-architecture i386 sudo apt update sudo apt install libc6:i386 libncurses5:i386 libstdc++6:i386

不过现在大多数官方工具链都提供 x86_64 主机版本，优先选 x86_64 版，省去 32 位兼容麻烦。如果非要用老工具链，Docker 容器是最省心的隔离方案。

6. 常见问题与排查技巧实录

交叉编译的报错往往很长，但真正有用的信息就几行。我的习惯是编译时加V=1或-v，先看实际调用的编译器和链接器命令，再判断是工具链没找到、头文件路径不对，还是链接库用错了架构。

6.1 工具链命令找不到、版本混乱怎么办

报aarch64-linux-gnu-gcc: command not found，先看 PATH：

echo $PATH which -a aarch64-linux-gnu-gcc

如果which -a找到多个，确认当前用的是哪个。多版本共存时，不要依赖全局 PATH，最好在项目脚本里显式指定绝对路径。另一个坑是CROSS_COMPILE和实际命令前缀不一致，比如设了CROSS_COMPILE=aarch64-linux-gnu-，但装的是aarch64-none-linux-gnu-gcc，内核编译就会找不到编译器。这种情况下要么改CROSS_COMPILE，要么在工具链目录里做符号链接。

6.2 头文件、库文件找不到的定位方法

报fatal error: openssl/ssl.h: No such file or directory，说明编译器找不到目标板头文件。先确认 sysroot 里有没有这个头文件：

find /opt/sysroot/cm5 -name ssl.h

如果 sysroot 里没有，就需要交叉编译 OpenSSL 并安装到 sysroot。注意不要在宿主机apt install libssl-dev后直接把/usr/include/openssl加到-I，那是 x86_64 头文件，可能能编译但链接会失败。用 pkg-config 时也要小心：

export PKG_CONFIG_SYSROOT_DIR=/opt/sysroot/cm5 export PKG_CONFIG_LIBDIR=/opt/sysroot/cm5/usr/lib/aarch64-linux-gnu/pkgconfig:/opt/sysroot/cm5/usr/share/pkgconfig

这样 pkg-config 才会从目标 sysroot 找.pc文件，而不是宿主机的。

6.3 ABI、浮点、GLIBC 版本不匹配的排查

ABI 问题最典型的表现是：编译通过，上板子报No such file or directory、Illegal instruction、GLIBC_2.34 not found。排查顺序：先file看架构，再readelf -A看浮点 ABI，再readelf -l看动态解释器，最后在板子上ldd --version看 glibc 版本。如果板子 glibc 低于编译时使用的 glibc，最简单的办法是用目标板 sysroot 重新编译，或者使用厂商提供的旧版工具链。

6.4 一份常见报错速查表

除了上面这些，Qt 和 Boost 交叉编译还有几个高频问题。

最后再分享一个我常用的 CMake 交叉编译文件模板，放在项目根目录toolchain.cmake：

set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR aarch64) set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc) set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g++) set(CMAKE_SYSROOT /opt/sysroot/cm5) set(CMAKE_FIND_ROOT_PATH /opt/sysroot/cm5) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

配置时用cmake -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake ..，CMake 就会自动从 sysroot 找头文件和库，避免误用宿主机依赖。这个文件配合env.sh一起用，基本上能覆盖大部分 ARM-Linux 交叉编译项目的日常需求。