B 站更新｜软考架构师案例篇・软件架构设计篇第 5 集上线｜微服务架构精讲｜24‑25 连续真题考点
2026/9/16 9:06:49
我前阵子接到一个活儿：一台aarch64的工控机，系统里没有gcc，更没有Qt运行库，文件系统又是只读的，想往上面跑一个带界面的Qt程序。折腾到最后，最靠谱的方案就是静态交叉编译——在x86的开发机上用aarch64交叉工具链，把Qt 5.14.2和应用程序一起编译成一个不依赖目标设备任何库的ELF可执行文件，拷过去直接跑。
这篇就把整个环境从零搭建到最终出包的过程完整记录下来。里面包含工具链与sysroot的选型、依赖库怎么处理、configure参数逐条拆解、编译和链接阶段的经典报错排查，以及最后在目标机上验证产物时容易栽进去的几个坑。想给ARM64设备交付Qt软件的朋友，这份手册可以直接照着抄。
1. 动手之前：版本、工具链与目标架构三件事先定死
1.1 为什么这个场景非选 Qt 5.14.2 不可
交叉编译最怕的就是版本选错、选太新，资料少、依赖变化大。Qt 5.14.2属于5.14系列，稳定性在嵌入式圈子里口碑不错，很多工控板卡厂商的BSP里默认带的都是这一条线的Qt库。它对Linux平台抽象层（QPA）里的linuxfb、eglfs这些后端支持非常成熟，做车载屏、工控HMI、瘦客户机界面都够用。
从技术角度看，5.14.2的源码包里自带了zlib、libpng、libjpeg、harfbuzz、pcre2、sqlite等大量第三方库，可以通过-qt-*系列参数让Qt直接用源码树里那份，避免外部依赖链越拉越长。这一点对静态编译来说简直是救命稻草。相比之下，Qt 6.x在交叉编译时要处理的CMake工具链配置、python依赖明显更重，而Qt 5.15虽然还在补丁期，但5.14.2的资料量和稳定性更稳妥，尤其是网上能搜到的aarch64下踩坑经验，绝大多数都基于5.14或5.15。
另外要明白，Qt官方不提供aarch64 Linux离线安装包，你想在ARM设备上装Qt，基本只有两条路：要么在设备上现场编译，要么就是在x86主机上交叉编译。设备上现场编译一个完整Qt耗时太长且会污染只读文件系统，交叉编译是唯一符合工程交付的做法。
1.2 交叉工具链：系统源里的 aarch64-gcc 就够用
交叉工具链我推荐直接用Ubuntu自带的，干净又好卸载：
sudo apt update sudo apt install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu aarch64-linux-gnu-g++ --version这个包安装后，编译器、链接器、ar、strip、objcopy全部带上前缀aarch64-linux-gnu-，sysroot自动指向/usr/aarch64-linux-gnu。比如你搜索一个arm64版的库，会出现在/usr/aarch64-linux-gnu/lib和/usr/aarch64-linux-gnu/include下面，而不是宿主机自己的/usr/lib和/usr/include。这条隔离规则非常重要，交叉编译的依赖库必须装到工具的sysroot里，绝不能让configure脚本搜到x86宿主机上的头文件和库，否则后续会出现各种匪夷所思的“Wrong ELF class”或头文件版本错乱问题。
关于工具链版本：Ubuntu 20.04/22.04自带的gcc 9/10/11系列编译Qt 5.14.2一点问题都没有，不需要去折腾Linaro或ARM官方工具链。只有一种情况例外——目标设备里的glibc版本特别老（比如老板子还是2.17的），那才需要考虑用Linaro提供的早期工具链。绝大多数人都遇不到这个场景，系统源方案最省心。
1.3 目标架构先确认好，别编译到一半才后悔
拿到目标设备第一件事，在设备上执行：
uname -m输出是aarch64就说明是ARMv8/AArch64 64位架构，配aarch64-linux-gnu-g++没问题。如果看到的却是armv7l，那是32位ARM，工具链要换成arm-linux-gnueabihf-，Qt的mkspec也完全不同。这个判断务必在开头做掉，不然编译了半天，最后拷到设备上“Illegal instruction”或者“Exec format error”，心态直接崩。
另外，交叉编译和普通编译的用途差别要搞清楚：普通编译在x86上生成x86二进制，静态编译在x86上生成一个不带动态依赖的x86二进制；而“静态交叉编译”是两者叠加，生成的aarch64二进制在目标设备上不依赖任何额外的so文件。后面所有工作都是围绕“静态”和“aarch64”这两个词展开的。
2. 依赖库地基：一个-qt-参数能带过，绝不手工造轮子
2.1 哪些库要预先交叉编译，哪些直接用Qt自带的
网上很多Qt交叉编译教程第一步就让你去编译zlib、libpng、libjpeg、sqlite、openssl，看得人头皮发麻。实际上Qt 5.14.2非常贴心地提供了“嵌入式小依赖”策略，configure的时候加这几个参数：
-qt-zlib -qt-libpng -qt-libjpeg -qt-freetype -qt-harfbuzz含义是让Qt在编译时直接使用qtbase源码里src/3rdparty目录下的这些库源码，编译成Qt静态库的一部分。这样一来，你完全不需要提前在sysroot里准备它们的aarch64版本，也不用管它们自己的交叉编译配置。这是整个搭建流程里最省时间的一步。
我整理了一个依赖处理总表，建议照着这个思路走：
| 库/组件 | 处理方式 | 原因说明 |
|---|---|---|
| zlib、libpng、libjpeg、freetype、harfbuzz | 使用-qt-*参数启用源码内构建 | Qt自带这些库的完整源码，避免外部交叉编译 |
| openssl | -no-openssl暂时禁用 | 静态编译openssl要处理libcrypto的依赖闭环，对纯界面应用收益不大 |
| xcb、X11 | -no-xcb禁用 | 目标设备是无桌面嵌入式环境，不需要X Window |
| OpenGL/EGL | -no-opengl禁用 | 如果做2D界面或linuxfb显示，不依赖GPU驱动栈 |
| libuuid | 手动交叉编译或裁剪特性 | Qt的configure有时会探测系统uuid库，sysroot里没头文件就报错 |
| sqlite | 默认走-qt-sqlite源码内构建 | Qt自带sqlite插件，不开外部版本反而省事 |
2.2 唯一可能需要手动编译的：libuuid
我在实际操作中遇到configure阶段明确报uuid/uuid.h: No such file or directory，这是Qt的configure脚本探测libuuid特性时找不到包导致的。网上最简单的说法是“sudo apt install libuuid-dev:arm64”，但在我这边这条命令把arm64包装到了宿主机的multiarch目录，与交叉工具链的sysroot对不上，反而引出新的头文件混乱。
当时我的处理方式，是下载e2fsprogs源码，只交叉编译其中的libuuid并安装到sysroot：
wget https://mirrors.edge.kernel.org/pub/linux/utils/util-linux/.../e2fsprogs-1.47.0.tar.gz tar xf e2fsprogs-1.47.0.tar.gz cd e2fsprogs-1.47.0 export PKG_CONFIG_LIBDIR=/usr/aarch64-linux-gnu/usr/local/lib/pkgconfig ./configure --host=aarch64-linux-gnu --prefix=/usr/aarch64-linux-gnu/usr/local make -C lib/uuid -j$(nproc) make -C lib/uuid install这样/usr/aarch64-linux-gnu/usr/local/include/uuid/uuid.h和静态库/usr/aarch64-linux-gnu/usr/local/lib/libuuid.a就位，Qt configure再探测时就能顺利通过。如果你的目标环境压根不需要uuid这个feature，也可以尝试在configure参数里通过-no-feature-libuuid直接关掉探测，但不同小版本支持情况有差异，我建议手动编译libuuid最保险。
2.3 如果以后要启用 openssl，提前留好编译位
这次先把openssl禁用了，但很多项目跑着跑着就要上HTTPS，到时候再回来编译openssl也来得及。openssl的交叉编译命令非常简单：
./Configure linux-generic64 no-shared --prefix=/usr/aarch64-linux-gnu/usr/local --cross-compile-prefix=aarch64-linux-gnu- make -j$(nproc) make install编译出的libssl.a和libcrypto.a直接进入sysroot，然后重新配置Qt时把-no-openssl换成-openssl-linked，并确认PKG_CONFIG_LIBDIR指向sysroot的pkgconfig目录，就可以在QtNetwork里启用HTTPS了。这个步骤我放后面做，前期不碰它，确保整体链路最短。
3. configure参数逐条拆解：静态、平台、模块裁剪缺一不可
3.1 一条能跑通的完整configure命令
进入qt-everywhere-src-5.14.2源码目录后，我建议先建一个build目录，源码树保持干净，方便后续查问题或重新配置：
mkdir -p /opt/qt-build/build-aarch64 cd /opt/qt-build/build-aarch64 /path/to/qt-everywhere-src-5.14.2/configure \ -prefix /opt/qt-5.14.2-aarch64 \ -xplatform linux-aarch64-gnu-g++ \ -static \ -release \ -opensource -confirm-license \ -no-opengl \ -no-xcb \ -no-feature-xcb \ -skip qtwebengine \ -skip qtwayland \ -skip qtscript \ -qt-zlib -qt-libpng -qt-libjpeg -qt-freetype -qt-harfbuzz \ -no-openssl \ -nomake examples -nomake tests -nomake tools \ -sysroot /usr/aarch64-linux-gnu你可能会问为什么在源码目录外建build目录还能跑configure，因为Qt 5.14支持影子构建，生成的中间文件和源码分离，这对交叉编译来说非常友好。如果这个命令执行到一半想改参数，不用从头解压，把这个build目录删掉重建就行。
3.2 这条命令里每一个关键参数背后的逻辑
-prefix /opt/qt-5.14.2-aarch64：指定最终安装路径。注意它是“从sysroot角度看”的安装路径，后面qmake生成的应用Makefile会引用这个前缀下的库。整个安装目录最后可以直接拷贝或打包分发。-xplatform linux-aarch64-gnu-g++：这是整个交叉编译的核心。linux-aarch64-gnu-g++对应源码中qtbase/mkspecs/linux-aarch64-gnu-g++目录，里面有个qmake.conf文件描述了要用的编译器前缀。Qt的configure拿到这个参数后，所有内部编译、链接、打包步骤都会使用aarch64-linux-gnu-gcc和aarch64-linux-gnu-g++。-static：静态编译开关。它会影响Qt自身的构建方式，最终生成的libQt5Core.a、libQt5Gui.a等全部是静态库，并且qmake在生成应用Makefile时也会自动加上-static链接标志。-no-opengl -no-xcb -no-feature-xcb：嵌入式设备没有X Window和OpenGL，去掉它们可以砍掉一大批依赖检查。其中-no-xcb关闭xcb插件构建，-no-feature-xcb关闭QtGui库里对xcb支持特性的编译。对纯Qt Widgets程序跑linuxfb来说，这两个都不需要。-skip qtwebengine：qtwebengine是Chromium内核，交叉编译aarch64版本需要下载大量第三方工具链且编译时间以天计，99%的嵌入式界面项目用不到，直接从构建列表里剔除。-sysroot /usr/aarch64-linux-gnu：显式告诉configure，系统库和头文件的根目录在这里。如果你不写，工具链默认会用自己的sysroot，有可能把编译器自带的C++头文件目录和系统库目录混在一起，configure探测结果会很随机。显式指定后，所有头文件搜索和库搜索均以该目录为根。
3.3 mkspec找不到时自己造一个：qmake.conf 修改法
我遇到过一次configure报Could not find qmake spec 'linux-aarch64-gnu-g++'的情况，原因是下载的源码包被裁剪过，mkspecs目录不完整。此时最简单的做法是复制一个近似的spec，然后改成arm64：
cp -r /path/to/qt-everywhere-src-5.14.2/qtbase/mkspecs/linux-arm-gnueabi-g++ \ /path/to/qt-everywhere-src-5.14.2/qtbase/mkspecs/linux-aarch64-my-g++然后编辑这个新目录下的qmake.conf，把里面的编译器命令改成aarch64版本：
QMAKE_CC = aarch64-linux-gnu-gcc QMAKE_CXX = aarch64-linux-gnu-g++ QMAKE_LINK = aarch64-linux-gnu-g++ QMAKE_LINK_SHLIB = aarch64-linux-gnu-g++ QMAKE_AR = aarch64-linux-gnu-ar cqs QMAKE_STRIP = aarch64-linux-gnu-strip QMAKE_OBJCOPY = aarch64-linux-gnu-objcopy QMAKE_NM = aarch64-linux-gnu-nm这里特别容易踩的坑是QMAKE_AR没改，导致Qt打包静态库时用的还是宿主x86的ar工具。虽然静态库.a的格式是统一的，但在configure阶段有些特性测试会调用ar去创建测试库，命令名前缀不对就会找不到工具或构建出宿主格式的归档文件。所以五个工具全都要换成aarch64前缀。
改完后，把configure命令里的-xplatform linux-aarch64-gnu-g++改成-xplatform linux-aarch64-my-g++，其余不变，configure就能继续跑。
3.4 模块裁剪：少编译一个模块，少踩一片坑
Qt整个仓库有几十个模块，交叉编译全量编译会带来几个后果：时间暴涨、磁盘占用暴涨、第三方依赖变多、报错概率变高。我的裁剪思路是：只保留Qt应用最常用的基础模块，其他的全部skip。实际需要保留的模块有qtbase、qtdeclarative、qttools（可选）、qtsvg（如果需要矢量图）。如果是纯Widgets程序，连qtdeclarative都可以不要。
常见可以放心跳过的模块和理由：
| 模块 | 为什么跳过 |
|---|---|
| qtwebengine | Chromium交叉编译复杂度极高，时间成本大 |
| qtwayland | 无Wayland显示服务环境就用不上 |
| qtscript | 已废弃，Qt6彻底移除 |
| qtquick3d | 高性能3D场景非必需 |
| qtdoc、qtqa、qtrepotools | 文档、测试、仓库工具，生产环境无用 |
裁剪后configure阶段会打印一张“Modules in configuration”列表，自己检查一下QPA backends里有没有linuxfb，这一步非常重要，后面目标机上能不能出画面全靠它。
4. make构建与安装：耗时、提速和编译期错误现场
4.1 编译命令、核数与安装路径验证
configure正常结束并打印Qt is now configured for building后，开始编译：
make -j$(nproc) 2>&1 | tee build.lognproc在8核机器上会变成8，内存如果不到8G建议手动-j4，否则编译过程中的并行g++进程容易把内存撑爆，直接导致“internal compiler error: Killed”。编译Qt的静态库时，每个编译单元都带大量模板实例化和内联展开，单个g++进程能吃掉1~2G内存，所以内存比核心数更容易成为瓶颈。
我第一次全量编译大约花了1个半小时，机器是8核16G。编译期间如果某个模块因为第三方库缺少而失败，不需要重头再来，直接在configure命令里把该模块加入-skip列表，重新建一个build目录配置并编译即可。
编译结束后安装：
make install检查安装结果是否真实可用的命令是看/opt/qt-5.14.2-aarch64/bin/qmake是否存在，并且执行：
/opt/qt-5.14.2-aarch64/bin/qmake -query输出里QT_HOST_PREFIX对应的如果是/opt/qt-5.14.2-aarch64，QT_TARGET_ARCH如果是aarch64，就算安装成功。注意qmake -query输出里的QT_HOST_*和QT_TARGET_*两个命名空间，交叉编译后它们并不相同，这是边界感很重要的一次体现。
4.2 编译期高频报错与现场修复记录
编译期不是所有错误都来自模块源码本身，我遇到最多的是configure在探测阶段埋下的隐患，真正的编译阶段反而相对顺利。如果你在configure阶段看到这类报错：
ERROR: Feature 'system-zlib' was enabled, but the system library is not available这是configure认为你声明了使用系统zlib，但sysroot里没有。解决办法是给configure加上-qt-zlib，所有依赖库统一走源码内构建，这类错误就从根本上消除了。类似地，凡是报“system-xxx is enabled but not available”的，就改用对应的-qt-xxx参数。
如果报错出现在具体模块源码编译过程中，先去查这个模块依赖了哪个外部库。比如qtimageformats模块如果依赖外部的webp、tiff库，而你没有在sysroot里补上，它就会中途失败。既然不需要这些图像格式，直接在configure命令里加-skip qtimageformats把它跳过去，比去费劲交叉编译一堆图像解码库划算得多。
4.3 链接阶段的经典报错：静态库顺序与-Wl,--start-group
Qt自带的模块通常能顺利链接，但当你自己的程序逐渐变大，引入的第三方静态库会带来一系列链接顺序问题。静态库链接的规则是“谁依赖谁，谁就排在前面；被依赖的库永远排在后面”。比如你的程序用到了libpng，而libpng内部又依赖zlib，链接命令行顺序必须至少是：
-lpng -lz如果写成-lz -lpng，多数情况下链接器还是能过的，因为现代链接器有垃圾回收和组扫描机制，但一旦涉及时序复杂的库（比如libxml2依赖lzma、zlib、iconv多个库），单靠人工排顺序就非常痛苦。
这时候可以用链接器的组扫描参数一次解决：
LIBS += -Wl,--start-group -lz -lpng -ljpeg -Wl,--end-group--start-group包围的库会被链接器反复扫描直到所有符号引用都满足，循环依赖也能解开。Qt静态库之间偶尔也会出现这种互相引用，如果你在链接应用时看到大量未定义符号，但又确定这些符号确实存在某个libQt开头的库里，就用组扫描包一圈。注意这个参数不要滥用，把整条命令行都包进去会让链接时间显著变长。
5. 交叉编译第一个Qt窗口程序并验证产物
5.1 用交叉qmake生成工程Makefile
交叉安装完成后，编译应用程序基本就是水到渠成。先写一个最小验证程序main.cpp：
#include <QApplication> #include <QLabel> int main(int argc, char *argv[]) { QApplication app(argc, argv); QLabel label("hello aarch64 static"); label.resize(320, 200); label.show(); return app.exec(); }工程文件hello.pro：
QT += core gui widgets TARGET = hello_aarch64 TEMPLATE = app SOURCES = main.cpp构建时，不要直接输入qmake，要明确用交叉编译后的那个qmake，否则系统原有的x86版qmake会跑来做宿主构建：
/opt/qt-5.14.2-aarch64/bin/qmake hello.pro make -j$(nproc)如果你在工程里加入了第三方静态库路径，记得在.pro里写：
INCLUDEPATH += /usr/aarch64-linux-gnu/usr/local/include LIBS += -L/usr/aarch64-linux-gnu/usr/local/lib5.2 file、ldd、readelf 三条命令看穿产物
编译完成后，验证静态交叉编译是否成功有三板斧：
file hello_aarch64正常输出应该是：
ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked这里看到ARM aarch64说明架构正确，看到statically linked说明静态链接生效。如果输出里出现dynamically linked，说明.pro中少了静态标志，回到工程文件添加：
QMAKE_LFLAGS += -static再执行ldd hello_aarch64，静态二进制会直接提示“不是动态可执行文件”或“statically linked”，说明它已经不再依赖任何so，拷到目标设备上运行不需要带任何Qt库。最后用aarch64-linux-gnu-readelf -h hello_aarch64确认ELF头的Machine字段是AArch64，这一步可以作为发布前的自动化检查脚本。
5.3 静态插件导入：漏了它，窗口根本起不来
这里有个非常隐蔽的坑：Qt把很多功能做成插件，比如linuxfb平台插件、png格式插件、字体引擎插件。动态编译时，这些插件以so形式放在plugins/目录下，运行时按需加载；静态编译时，插件被编成了.a静态库，但不会自动进入你的可执行文件，必须显式声明。
最简单的做法是在.pro里声明：
QTPLUGIN += qlinuxfb qgif或者更直接地，在main.cpp里手动导入：
#include <QtPlugin> Q_IMPORT_PLUGIN(qlinuxfb)如果没有这一步，程序在目标机上会报：
This application failed to start because no Qt platform plugin could be initialized.这个错误信息几乎可以断定是静态插件没链进去，而不是系统配置问题。处理完插件链接后，应用运行前还要设置QPA平台：
export QT_QPA_PLATFORM=linuxfb ./hello_aarch64linuxfb模式直接写framebuffer节点/dev/fb0，不需要X Server、Wayland或任何窗口管理器，这是无桌面嵌入式设备上的最佳选择。
6. 踩坑实录：从configure到目标机运行的完整排查链路
6.1 坑一：uuid/uuid.h not found——configure探针的“误伤”
第一个让我头疼的报错出现在configure阶段：
checking for uuid/uuid.h... no随后编译直接中断，提示找不到uuid/uuid.h。其实我的程序从头到尾没用过uuid库，但Qt的configure脚本把这个feature默认置为有系统依赖。排查路径是这样的：
- 打开
config.log，搜索uuid/uuid.h，看到失败记录是编译器尝试includeuuid/uuid.h但路径不存在。 - 检查sysroot的
/usr/aarch64-linux-gnu/usr/local/include，确实没有uuid头文件。 - 决定按2.2节的方式编译libuuid进sysroot，让探查通过。
这个坑提醒我：Qt的configure是一个“特性全探测”脚本，它会检测系统能力来决定启用哪些功能，交叉编译环境下这些探测全部依赖sysroot内容的完整性。与其在报错后一个个补库，不如一开始就确定好sysroot里要有什么，并在configure命令里裁剪掉不需要的feature。
6.2 坑二：undefined reference to 'inflate'——静态链接顺序造成的假象
链接自己的应用时，遇到一堆未定义引用：
libQt5Core.a(qzlib.cpp.o): In function `QZlibStream::decompress': undefined reference to `inflate'明明加了-lz，为什么还是找不到？问题出在链接顺序上：Qt的.a静态库在命令行中的位置靠前，它内部的inflate符号解析时，链接器还没扫描到后面的-lz，自然报未定义。
我当时的解决方式是在.pro文件里使用组扫描参数，把Qt库和zlib放在同一个组里：
QMAKE_LFLAGS += -static LIBS += -Wl,--start-group -lQt5Widgets -lQt5Gui -lQt5Core -lz -ldl -lpthread -Wl,--end-group静态库互相依赖的循环关系，用组扫描一次解决。这条经验之后我处理所有第三方静态库都很通用，凡是链接阶段出现“明明有符号但解析不了”，第一反应就是检查链接顺序或者干脆上组扫描。
6.3 坑三：目标机上段错误还是Could not load platform plugin
把hello_aarch64拷贝到目标设备后，第一次运行并没有出现窗口，而是报错：
This application failed to start because no Qt platform plugin could be initialized.我的第一反应是检查plugins/platforms目录是否存在。但静态编译的二进制根本没有目录概念，问题在于我没把linuxfb插件静态导入。加入Q_IMPORT_PLUGIN(qlinuxfb)后，错误变成了：
Segmentation fault这就更不能忍了。排查链路是这样的：
- 先确认CPU架构：目标设备
uname -m输出必须是aarch64，符合预期。 - 用
aarch64-linux-gnu-readelf -h hello_aarch64确认ELF Machine字段是AArch64。 - 检查目标设备上是否有
/dev/fb0，嵌入式设备如果内核没开fbdev或分辨率不对，linuxfb插件初始化会失败。执行ls /dev/fb*，发现/dev/fb0确实存在。 - 在目标机上加调试输出：
export QT_DEBUG_PLUGINS=1，运行后打印全插件加载过程，最后定位到“Cannot open display”并不是dispay问题，而是没有指定QPA平台。
最终设置：
export QT_QPA_PLATFORM=linuxfb export QT_QPA_FB_DRM=1 ./hello_aarch64窗口正常显示。这个坑说明，静态Qt程序运行时的环境变量依然很重要，静态只解决“依赖库”问题，不解决“运行时设备配置”问题。
6.4 config.log定位问题：比搜索引擎更直接的唯一真源
凡是configure阶段出问题，不管报错多吓人，我的第一动作永远是：
grep -n "error\|Error\|ERROR\|not found\|No such" config.log | head -50config.log会记录configure期间执行的每一条测试命令及其输出，你看到的报错信息往往只是它最后搭起的冰山一角。比如编译xcb相关feature失败时，屏幕只显示一句“Basic XLib functionality test failed”，但config.log里能看到具体的编译器报错是GL/gl.h not found还是xcb.h not found，从而决定是补库还是禁feature。
另外强烈建议在configure前设置环境变量：
export PKG_CONFIG_LIBDIR=/usr/aarch64-linux-gnu/usr/local/lib/pkgconfig:/usr/aarch64-linux-gnu/lib/aarch64-linux-gnu/pkgconfig export PKG_CONFIG_SYSROOT_DIR=/usr/aarch64-linux-gnu这样pkg-config只会在sysroot里找.pc文件，不会探测到宿主x86的依赖环境。很多明明交叉编译了某个库，configure却依然说找不到的灵异事件，多半就是PKG_CONFIG_LIBDIR没设置对。
7. 环境搭好之后还能做什么
当这套交叉编译环境完整跑通后，你得到的其实不只是Qt的编译器工具链，而是一个完整的aarch64静态编译平台。同一个sysroot、同一套aarch64-linux-gnu-前缀工具链、同一个pkg-config配置，可以用来交叉编译大量在ARM64服务器或嵌入式设备上运行的C/C++程序。
比如nginx这类高性能组件，交叉编译时只需指定编译器：
./configure --with-cc=aarch64-linux-gnu-gcc --with-ld-opt="-static" --without-http_rewrite_module这里的依赖逻辑和Qt完全一致：静态链接时，编译器找头文件从/usr/aarch64-linux-gnu下的路径找，pkg-config配置指向sysroot，最后用file命令验证。甚至phantomjs这类缺少官方aarch64预编译二进制的项目，只要你能拿到对应的WebKit源码并愿意花时间去适配，这套环境也是基础。
个人觉得最值回票价的其实是省下的时间成本。初次搭建静态交叉编译Qt环境，从工具链选型到最终目标机跑通，我前后花了两三天，大部分时间都耗在configure探测和插件导入上。环境搭好后，后续每个Qt工程从写代码到产出aarch64静态二进制，基本十分钟以内就能完成。以后再接ARM设备上的界面项目，开发、编译、部署、验证的路径就固化下来了，不需要每次都从零开始摸黑。