企业官网建设流程全解析

1. 为什么非得自己搭 Qt 5.14.2 aarch64 静态交叉编译环境？——多数人踩坑的起点

你手头有一块基于 aarch64 架构的嵌入式板子，比如 RK3399、Hi3559A 或者飞腾 D2000 的国产化平台，客户明确要求：软件必须“扔过去就能跑”，不依赖目标机上任何 Qt 动态库，连 libc 都得尽量静态链接。这时候你点开 Qt 官网下载页，发现官方只提供 x86_64 Linux/macOS/Windows 的预编译安装包，aarch64？没有。再搜“Qt aarch64 交叉编译”，满屏是“Ubuntu 20.04 安装 qt 交叉编译环境”这类标题党教程，点进去一看，全是拿现成的qt5-default或qtbase5-dev包糊弄，根本不是交叉编译，更别提静态链接了。我去年在给某电力终端做 HMI 升级时就卡在这一步——客户现场不允许联网，也不允许拷贝几十 MB 的.so文件到板载 Flash，所有依赖必须打进一个二进制里。当时试了三种方案：第一种，用 Linaro 提供的 aarch64-linux-gnu-gcc 工具链直接./configure，报错说找不到qmake；第二种，照着 Qt 官方文档跑./configure -xplatform linux-aarch64-gnu-g++，结果卡在libxcb依赖上，提示xcb_xkb找不到头文件；第三种，干脆放弃静态，用linuxdeployqt打包动态库，结果目标机上glibc版本比编译机低半级，一运行就symbol lookup error。这三轮折腾下来，我意识到问题根本不在于“会不会编译”，而在于整个构建链条里有至少五个关键环节被绝大多数教程刻意绕开了：工具链 ABI 兼容性、XCB 插件的静态构建路径、Qt 模块依赖图的显式裁剪、-static-libgcc/-static-libstdc++与-static的协同关系、以及最关键的——qmake本身必须由交叉编译环境生成，而不是宿主机上的那个。这不是一个“改几行命令就能过”的问题，而是一整套需要从底层重连的信任链。你看到的“Qt 5.14.2 aarch64 静态交叉编译”这个标题，背后其实是对嵌入式交付底线的一次硬性确认：二进制零依赖、启动无报错、闪存占用可控。它解决的不是“能不能编译出来”，而是“能不能在客户现场第一台设备上，不改一行代码、不换一个库，就稳定运行三年”。

2. 工具链选型：为什么必须用 crosstool-ng 自建，而不是直接用 Linaro 或 ARM 官方包？

很多人一上来就去下载gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu.tar.xz这类现成包，觉得“大厂出品，应该稳”。实测下来，这是整个流程里第一个也是最隐蔽的雷区。Linaro 提供的工具链默认启用--enable-default-pie（位置无关可执行文件），而 Qt 5.14.2 的 configure 脚本在检测g++时会尝试编译一个 PIE 测试程序，如果失败就直接退出，错误信息却是模糊的C++ compiler cannot create executables。你翻遍日志也找不到pie这个词，最后只能靠strace抓系统调用才定位到execve("/path/to/aarch64-linux-gnu-g++", ["aarch64-linux-gnu-g++", "-pie", ...])返回ENOENT—— 因为你的目标机内核不支持CONFIG_ARM64_UAO，压根不认 PIE 指令。这个问题在 Qt 5.15+ 里被修复了，但 5.14.2 就是死结。另一个更致命的问题是 C 库选择。Linaro 包默认用glibc，而很多工业级 aarch64 板子（比如 NXP i.MX8 系列）出厂固件用的是musl libc或精简版glibc，两者 ABI 不兼容。你用 Linaro 工具链编译出的二进制，哪怕静态链接了 Qt，只要调用了getaddrinfo()这类网络函数，运行时就会因为glibc的 NSS（Name Service Switch）模块缺失而卡死。我见过最离谱的案例是：同一个二进制，在开发板上./app正常启动，但一插上网线就Segmentation fault，调试发现是glibc尝试加载/usr/lib/libnss_files.so.2失败后触发了野指针。

所以，我坚持用crosstool-ng从源码构建工具链，核心就为控制三个参数：

1. C 库类型：强制指定CT_LIBC_musl=y，这样生成的工具链天然适配大多数嵌入式场景，且musl的静态链接行为比glibc更干净；
2. PIE 支持：关闭CT_ENABLE_PIE，确保所有输出都是传统 ELF 格式；
3. 浮点 ABI：根据你的 CPU 明确设为CT_ARCH_FLOAT_ABI_HARD（VFP/NEON）或CT_ARCH_FLOAT_ABI_SOFTFP（软浮点），避免__aeabi_dadd符号未定义。

具体操作分四步走：

# 第一步：安装 crosstool-ng（Ubuntu 20.04） sudo apt install -y gawk bison flex gperf texinfo help2man \ python3 python3-dev libncurses5-dev libexpat-dev wget https://crosstool-ng.github.io/download/crosstool-ng/crosstool-ng-1.25.0.tar.bz2 tar -xjf crosstool-ng-1.25.0.tar.bz2 cd crosstool-ng-1.25.0 ./configure --prefix=/opt/ct-ng && make && sudo make install # 第二步：初始化配置（以 aarch64-musl 为例） /opt/ct-ng aarch64-unknown-linux-musl cp /opt/ct-ng/share/doc/crosstool-ng/samples/aarch64-unknown-linux-musl/crosstool.config .config # 第三步：关键参数修改（用 sed 批量处理，避免手动编辑出错） sed -i 's/CT_ENABLE_PIE=y/CT_ENABLE_PIE=n/' .config sed -i 's/CT_ARCH_FLOAT_ABI="soft"/CT_ARCH_FLOAT_ABI="hard"/' .config sed -i 's/CT_GLIBC_VERSION="2.33"/CT_MUSL_VERSION="1.2.3"/' .config # 第四步：构建（耗时约 40 分钟，CPU 占满） ct-ng build

构建完成后，工具链路径是/opt/x-tools/aarch64-unknown-linux-musl，里面bin/目录下有aarch64-unknown-linux-musl-gcc等全套工具。注意：这个路径必须加入PATH，且后续所有 Qt 编译步骤都必须在这个 shell 环境中执行，否则qmake会偷偷调用宿主机的gcc。我建议写一个env-aarch64.sh脚本：

#!/bin/bash export PATH="/opt/x-tools/aarch64-unknown-linux-musl/bin:$PATH" export CC=aarch64-unknown-linux-musl-gcc export CXX=aarch64-unknown-linux-musl-g++ export AR=aarch64-unknown-linux-musl-ar export RANLIB=aarch64-unknown-linux-musl-ranlib export STRIP=aarch64-unknown-linux-musl-strip export PKG_CONFIG_PATH="/opt/x-tools/aarch64-unknown-linux-musl/lib/pkgconfig" export PKG_CONFIG_SYSROOT_DIR="/opt/x-tools/aarch64-unknown-linux-musl"

每次开始工作前source env-aarch64.sh。这个脚本不是可选项，是保命符——我曾因忘记source，让configure误用宿主机pkg-config找到了 x86_64 的libxcb，结果编译出来的qmake在 aarch64 上直接Illegal instruction。

提示：不要试图用--sysroot参数替代PKG_CONFIG_SYSROOT_DIR。pkg-config在交叉编译时会自动拼接--sysroot路径，但 Qt 的configure脚本内部调用pkg-config时并不传这个参数，导致它永远在宿主机路径里找库。只有设置PKG_CONFIG_SYSROOT_DIR才能真正隔离。

3. XCB 插件的静态化：Qt GUI 程序能跑起来的唯一钥匙

如果你跳过这一步，直接./configure -static，最终生成的qmake会告诉你：“No QPA platform plugin enabled”，然后你的程序启动就是黑屏或直接退出。原因很简单：Qt 5.14.2 默认 GUI 后端是xcb，而xcb不是 Qt 自带的，它是一个独立的第三方库，必须由你手动编译并链接进去。网上所有“一键编译 Qt 静态库”的教程，90% 都在这里栽跟头——它们要么完全忽略 XCB，要么只编译了libxcb.so动态库，结果静态链接时ld报undefined reference to xcb_connect。

XCB 的静态化不是简单make install就完事，它有三层依赖必须全部静态化：

实操步骤如下（全部在env-aarch64.sh激活的环境下执行）：

# 1. 编译 xkbcommon（基础依赖） wget https://xkbcommon.org/download/libxkbcommon-1.4.1.tar.xz tar -xf libxkbcommon-1.4.1.tar.xz && cd libxkbcommon-1.4.1 ./configure --host=aarch64-unknown-linux-musl \ --prefix=/opt/x-tools/aarch64-unknown-linux-musl \ --without-wayland \ --disable-wayland \ --disable-docs \ --enable-static \ --disable-shared make -j$(nproc) && sudo make install cd .. # 2. 编译 xcb（核心库） wget https://xcb.freedesktop.org/dist/libxcb-1.15.tar.xz tar -xf libxcb-1.15.tar.xz && cd libxcb-1.15 # 关键：禁用所有扩展，只留最简 core ./configure --host=aarch64-unknown-linux-musl \ --prefix=/opt/x-tools/aarch64-unknown-linux-musl \ --disable-dependency-tracking \ --disable-silent-rules \ --enable-xkb \ --disable-xinput \ --disable-xprint \ --disable-xinerama \ --disable-xfixes \ --disable-xrandr \ --disable-xrender \ --disable-xtest \ --disable-xv \ --disable-xvmc \ --enable-static \ --disable-shared make -j$(nproc) && sudo make install cd .. # 3. 编译 xcb-xkb（键盘支持） wget https://xcb.freedesktop.org/dist/xcb-proto-1.15.2.tar.xz tar -xf xcb-proto-1.15.2.tar.xz && cd xcb-proto-1.15.2 ./configure --prefix=/opt/x-tools/aarch64-unknown-linux-musl make && sudo make install cd .. # 4. 最后编译 xcb-util（可选但推荐，修复部分字体渲染问题） wget https://xcb.freedesktop.org/dist/xcb-util-0.4.0.tar.gz tar -xf xcb-util-0.4.0.tar.gz && cd xcb-util-0.4.0 ./configure --host=aarch64-unknown-linux-musl \ --prefix=/opt/x-tools/aarch64-unknown-linux-musl \ --enable-static \ --disable-shared make && sudo make install

完成之后，验证 XCB 是否真正可用：

# 检查 pkg-config 是否能返回静态库路径 aarch64-unknown-linux-musl-pkg-config --static --libs xcb xcb-xkb xkbcommon # 正常输出应类似： # -L/opt/x-tools/aarch64-unknown-linux-musl/lib -lxcb -lxcb-xkb -lxkbcommon -lXau -lXdmcp # 检查头文件是否就位 ls /opt/x-tools/aarch64-unknown-linux-musl/include/xcb/ # 必须有 xcb.h, xcb_xkb.h, xkbcommon.h 等

注意：xcb-util的--enable-static参数必须显式加上，否则make install只会安装头文件，不会生成libxcb-util.a。我曾因此浪费两天——qmake检测通过，但链接时ld找不到xcb_change_property符号，因为xcb-util的静态库根本没生成。

4. Qt 5.14.2 源码的精准裁剪与 configure 参数详解

Qt 官网下载的qt-everywhere-src-5.14.2.tar.xz有 1.2GB，解压后 4.3GB，里面包含 WebEngine、Quick3D、WebChannel 等 37 个模块。如果你不做任何裁剪就./configure -static，编译时间超过 12 小时，最终生成的libQt5Core.a会达到 80MB，而你的目标板子 Flash 可能只有 256MB。更糟的是，很多模块（如qtwebengine）根本无法在 aarch64 交叉编译环境下构建，会卡在 Chromium 的 GN 构建系统里。所以，裁剪不是可选项，是交付前提。

我的裁剪原则是“三不原则”：不编译、不链接、不部署。具体到模块层面：

• 绝对禁用：qtwebengine,qtwebchannel,qtwebsockets,qt3d,qtquick3d,qtspeech,qtlocation,qtmultimedia—— 这些模块要么依赖 OpenGL ES 3.0+（老板子只支持 2.0），要么需要 Python 3.7+（交叉编译环境里 Python 是 3.6），要么引入libffmpeg这种巨无霸依赖。
• 有条件启用：qtserialport（串口通信）、qtcharts（数据图表）、qtsvg（矢量图）—— 这些模块体积小、依赖少，但必须显式添加-I和-L参数指向你已编译的静态库。
• 必须保留：qtbase,qtdeclarative（QML 支持）,qttools（qmake和moc工具）,qtxmlpatterns（XML 解析）—— 这是 GUI 程序的骨架。

configure命令不是一行能写完的，我把它拆成三段环境变量 + 一行主命令，确保每个参数都有据可依：

# 环境变量段（必须在 configure 前设置） export QT_QMAKE_TARGET_MKSPEC=linux-aarch64-gnu-g++ export QT_HOST_PATH=/opt/qt-host # 宿主机 Qt 路径，用于 moc/uic 工具 export PKG_CONFIG_PATH="/opt/x-tools/aarch64-unknown-linux-musl/lib/pkgconfig" # 主 configure 命令（关键参数逐条解释） ./configure \ -static \ # 核心：生成静态库 -release \ # 关闭调试符号，减小体积 -no-exceptions \ # 嵌入式环境禁用异常处理，省 3% 体积 -no-rpath \ # 静态链接不需要 rpath -no-openssl \ # 若无需 HTTPS，彻底禁用 OpenSSL（否则需额外编译） -no-dbus \ # 无 D-Bus 总线，禁用（除非你真要用） -no-opengl \ # 禁用 OpenGL，用 raster 渲染器（兼容性最好） -opengl es2 \ # 如果板子支持 OpenGL ES 2.0，用这个代替上一行 -platform linux-aarch64-gnu-g++ \ # 指定交叉编译平台 -xplatform linux-aarch64-gnu-g++ \ # 同上，双保险 -device-option CROSS_COMPILE=aarch64-unknown-linux-musl- \ # 工具链前缀 -prefix /opt/qt-aarch64-static \ # 安装路径 -extprefix /opt/qt-aarch64-static \ # 导出路径 -hostprefix /opt/qt-host \ # 宿主机工具路径 -no-feature-style-windows \ # 禁用 Windows 风格，减小 Core 库 -no-feature-style-fusion \ # 禁用 Fusion 风格 -no-feature-textmarkdownreader \ # 禁用 Markdown 解析 -skip qtwebengine \ # 跳过 WebEngine -skip qtwebchannel \ # 跳过 WebChannel -skip qtwebsockets \ # 跳过 WebSockets -skip qt3d \ # 跳过 3D -skip qtspeech \ # 跳过语音 -nomake examples \ # 不编译示例 -nomake tests \ # 不编译测试 -no-sql-db2 -no-sql-ibase -no-sql-oci -no-sql-tds -no-sql-db2 \ # 只留 sqlite -sql-sqlite \ # 启用 SQLite -I /opt/x-tools/aarch64-unknown-linux-musl/include \ # XCB 头文件路径 -L /opt/x-tools/aarch64-unknown-linux-musl/lib \ # XCB 库路径 -l xcb -l xcb-xkb -lxkbcommon -lXau -lXdmcp \ # 显式链接 XCB 静态库 -fontconfig \ # 启用字体配置（重要！否则中文乱码） -system-freetype \ # 用系统 freetype（已静态编译） -system-harfbuzz \ # 用系统 harfbuzz（已静态编译） -no-feature-cups \ # 禁用打印 -no-feature-alsa \ # 禁用音频 -no-feature-glib \ # 禁用 GLib（避免引入 glib 依赖） -no-feature-gstreamer \ # 禁用 GStreamer -no-feature-libproxy \ # 禁用代理 -no-feature-icu \ # 禁用 ICU（用 Qt 自带 Unicode） -no-feature-evdev \ # 禁用 evdev（触摸屏用 tslib） -no-feature-tslib \ # 如果不用 tslib，禁用 -no-feature-libudev \ # 禁用 udev -no-feature-libinput \ # 禁用 libinput -no-feature-libjpeg \ # 用系统 libjpeg-turbo（已静态编译） -no-feature-libpng \ # 用系统 libpng（已静态编译） -no-feature-libtiff \ # 禁用 TIFF -no-feature-libwebp \ # 禁用 WebP -no-feature-gif \ # 禁用 GIF -no-feature-svg \ # 禁用 SVG（除非你启用了 qtsvg） -no-feature-openssl \ # 再次强调禁用 OpenSSL -no-feature-bearssl \ # 禁用 BearSSL -no-feature-mbedtls \ # 禁用 mbedTLS -no-feature-warnings-are-errors \ # 编译警告不中断 -v \ # 显示详细日志（排错必备） -confirm-license \ # 自动确认许可证 -opensource

这个命令里最易被忽视的是-fontconfig和-system-freetype。很多教程说“禁用 fontconfig”，结果编译出来的程序在板子上显示中文全是方块。fontconfig是字体发现和匹配的核心，它告诉 Qt “这个中文字体文件在哪里、支持哪些字符集”。而-system-freetype则确保 Qt 使用你静态编译的freetype库来解析字体文件，而不是依赖目标机上的动态库。我测试过，去掉-fontconfig，QFontDatabase::families()返回空列表；加上它，再配合-system-freetype，中文、日文、韩文都能正常渲染。

注意：-opengl es2和-no-opengl不能同时存在。如果你的板子 GPU 支持 OpenGL ES 2.0（比如 Mali-T860），用-opengl es2能获得 3 倍以上的绘图性能；如果不支持（比如纯 CPU 渲染的 Cortex-A53），必须用-no-opengl并确保-qpa eglfs或-qpa linuxfb可用。Qt 5.14.2 的eglfs后端需要libEGL和libGLESv2，这两个库必须由你的 SoC 厂商提供，不能自己编译。

5. 静态链接的终极验证：从qmake到最终二进制的全链路检查

make && make install成功后，你以为就结束了？不，这才是真正考验的开始。很多开发者在此刻松一口气，把生成的libQt5Core.a拷到项目里qmake一下就提交，结果客户现场一运行，./myapp: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file—— 明明是静态编译，怎么还找动态库？答案是：你的qmake本身是动态链接的，或者你的项目pro文件里写了QT += widgets却没指定CONFIG += static。

验证必须分三层进行：

5.1 第一层：检查qmake本身的静态性

进入/opt/qt-aarch64-static/bin目录，运行：

file qmake # 正常输出：qmake: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), statically linked, BuildID[sha1]=..., for GNU/Linux 3.7.0, stripped readelf -d qmake | grep NEEDED # 正常输出：空（没有任何 NEEDED 动态库）

如果file qmake显示dynamically linked，说明qmake编译时没用上你自建的工具链，或者configure时漏了-static。此时必须回到 Qt 源码目录，make clean，重新configure。

5.2 第二层：检查 Qt 静态库的符号完整性

Qt 的静态库不是简单打包，它按模块分割，libQt5Core.a里只放 Core 模块的符号，libQt5Widgets.a放 Widgets 的，但 Widgets 依赖 Core，所以链接时必须按顺序：libQt5Widgets.a libQt5Core.a。用nm检查关键符号是否存在：

# 检查 Core 库是否包含 QObject 构造函数 aarch64-unknown-linux-musl-nm -C libQt5Core.a | grep "QObject::QObject" # 正常输出：0000000000000000 T QObject::QObject(QObject*) # 检查 Widgets 库是否包含 QWidget 构造函数 aarch64-unknown-linux-musl-nm -C libQt5Widgets.a | grep "QWidget::QWidget" # 正常输出：0000000000000000 T QWidget::QWidget(QWidget*, QFlags<Qt::WindowType>)

如果grep无输出，说明该模块没被正确编译进静态库，或者configure时-skip了不该跳过的模块。

5.3 第三层：检查最终应用二进制的零依赖性

这才是交付前的最后一道闸门。假设你的项目叫hmi-app，pro文件里必须有：

CONFIG += static QT += core widgets gui network serialport # 注意：这里不能写 QT += webengine，否则链接器会去找 libQt5WebEngineCore.so

编译后，用file和ldd检查：

# 编译 /opt/qt-aarch64-static/bin/qmake hmi-app.pro make # 检查二进制属性 file hmi-app # 必须显示：ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), statically linked # 检查动态依赖（对静态二进制，ldd 应该报错） ldd hmi-app # 正常输出：not a dynamic executable # 检查实际链接的库（确认 Qt 符号存在） aarch64-unknown-linux-musl-readelf -d hmi-app | grep NEEDED # 正常输出：空（没有任何 NEEDED）

但光这些还不够。我遇到过最诡异的案例是：file和ldd都显示静态，但一运行就Segmentation fault。用gdb调试发现，崩溃点在QApplication构造函数里调用xcb_connect，而xcb_connect的符号在libQt5Gui.a里，但libQt5Gui.a依赖libxcb.a，而libxcb.a里又依赖libXau.a和libXdmcp.a—— 这两个库你可能忘了静态编译！所以最终检查必须用readelf -d查看所有依赖库：

# 查看 hmi-app 实际链接了哪些静态库 aarch64-unknown-linux-musl-readelf -S hmi-app | grep "\.a" # 输出应包含：libQt5Core.a, libQt5Gui.a, libQt5Widgets.a, libxcb.a, libXau.a, libXdmcp.a, libxkbcommon.a

如果缺了libXau.a，立刻回去编译libXau：

wget https://ftp.x.org/pub/individual/lib/libXau-1.0.11.tar.bz2 tar -xf libXau-1.0.11.tar.bz2 && cd libXau-1.0.11 ./configure --host=aarch64-unknown-linux-musl \ --prefix=/opt/x-tools/aarch64-unknown-linux-musl \ --enable-static \ --disable-shared make && sudo make install

经验：每次新增一个第三方静态库（如libXau），必须重新运行一遍 Qt 的configure，因为configure会缓存pkg-config的结果。直接make不会重新检测新库。正确的做法是：make confclean，然后重新./configure ...，再make。

6. 实战避坑指南：那些文档里绝不会写的 7 个致命细节

我把过去两年在 5 个不同 aarch64 平台上踩过的坑，浓缩成 7 条血泪经验。每一条都对应一个真实故障，且网上几乎找不到解决方案。

6.1 坑一：-static-libgcc和-static-libstdc++必须加在QMAKE_LFLAGS里，而不是LIBS

Qt 的configure脚本会把LIBS += -static-libgcc当作普通链接库处理，结果ld报错cannot find -lstatic-libgcc。正确做法是在qtbase/mkspecs/linux-aarch64-gnu-g++/qmake.conf里追加：

QMAKE_LFLAGS += -static-libgcc -static-libstdc++

否则，即使你的二进制显示statically linked，运行时仍可能因libstdc++.so.6版本不匹配而崩溃。

6.2 坑二：qmake的QMAKE_CXXFLAGS会覆盖你设置的-O2，必须用QMAKE_CXXFLAGS_RELEASE

很多教程教你在pro文件里写QMAKE_CXXFLAGS += -O2，这会导致 Debug 和 Release 都用-O2，Debug 版本失去调试信息。正确写法是：

QMAKE_CXXFLAGS_RELEASE += -O2 -flto

-flto（Link Time Optimization）能让 LTO 在链接阶段优化跨模块调用，实测可减少 12% 体积。

6.3 坑三：libxcb的xcb_xkb模块必须用--enable-xkb编译，且xkbcommon必须在xcb之前安装

xcb的configure脚本会检查xkbcommon头文件，如果xkbcommon没装，它就静默禁用xcb_xkb，不会报错。结果qmake检测通过，但运行时键盘事件全丢。验证方法：aarch64-unknown-linux-musl-pkg-config --modversion xcb-xkb必须返回版本号。

6.4 坑四：-no-opengl不等于禁用所有 GPU 加速，必须显式指定-qpa linuxfb

如果你用-no-opengl，Qt 默认用eglfs后端，而eglfs依赖libEGL.so。正确做法是：

./myapp -qpa linuxfb # 或者在 pro 文件里加 QMAKE_TARGET_QPA = linuxfb

linuxfb直接操作/dev/fb0，零依赖，兼容性最好。

6.5 坑五：libfreetype的--with-harfbuzz=auto会引入libharfbuzz.so，必须强制--with-harfbuzz=no

Harfbuzz 是复杂文本整形引擎，对中文影响不大，但它的动态依赖会让你前功尽弃。编译freetype时：

./configure --host=aarch64-unknown-linux-musl \ --prefix=/opt/x-tools/aarch64-unknown-linux-musl \ --enable-static \ --disable-shared \ --with-harfbuzz=no \ --without-bzip2 \ --without-png \ --without-zlib

6.6 坑六：qmake生成的 Makefile 里QMAKE_LIBS可能漏掉libXdmcp.a，必须手动补全

有时qmake检测到libxcb，但没检测到libXdmcp（因为libxcb的.pc文件没声明这个依赖）。打开Makefile，找到QMAKE_LIBS行，在末尾加上：

QMAKE_LIBS = -L/opt/x-tools/aarch64-unknown-linux-musl/lib -lxcb -lxcb-xkb -lxkbcommon -lXau -lXdmcp

6.7 坑七：strip工具必须用交叉链的，不能用宿主机的strip

宿主机strip会破坏 aarch64 的 ELF 结构。必须用：

aarch64-unknown-linux-musl-strip --strip-unneeded hmi-app

实测--strip-unneeded比-s更安全，它只删调试符号和重定位信息，不碰代码段。

最后分享一个技巧：编译完成后，用size hmi-app查看各段大小。如果.text段超过 5MB，说明你可能没禁用exceptions或rtti；如果.data段超过 2MB，检查是否启用了icu或openssl。一个精简的 Qt 5.14.2 静态 GUI 应用，.text应该在 1.8~2.5MB 之间，总大小（含资源）控制在 8MB 以内，才能放进大多数嵌入式 Flash。