1. 为什么选择这条“费力”的路静态交叉编译的前置决策先交代一下背景。我在接手一个 ARM64 工控网关项目时需要把 Qt5.14.2 跑在一台 aarch64 架构的嵌入式设备上设备存储空间只有 2GB文件系统还是只读挂载的。也就是说常规的动态库部署方案直接作废——我只有两条路要么把整个运行库塞进只读分区要么把用到的东西全部编译进一个可执行文件里。前者对依赖版本和更新简直就是灾难所以最终我选了后者Qt5.14.2 静态交叉编译。这个选择在很多人看来是“自找麻烦”。毕竟 Qt 官方一直强调静态链接的门槛许可证要求、插件系统需要手动处理、编译时间翻倍。但真实场景里静态交叉编译的收益太诱人了部署时只拷贝一个 ELF 文件目标机上不需要装任何 Qt 运行库版本冲突彻底消失不会出现“这台设备上 libQt5Core.so.5 被别的应用替换掉”这种坑对只读文件系统、离线环境、开机自启动场景非常友好调试时不用反复往板子上同步 .so 文件scp 一个二进制就完事。为什么是 Qt 5.14.2这是 5.14 LTS 分支的最后一个补丁版本也是 Qt 5 时代最后一个对老式编译器比较宽容的版本。它既不要求 GCC 9 才能编译又完整支持 CMake5.15 之后的每个新版本都在折腾构建系统而且 5.14 的 qmake 逻辑相当稳定网上资料也多。对于国产化芯片和长期维护的嵌入式项目来说Qt 5.14.2 几乎是当前最稳妥的“安全牌”。当然静态交叉编译也有明显的代价这点必须提前说清楚对比项动态编译静态编译部署复杂度需同步 Qt 库和依赖 .so单文件直接运行可执行文件体积小几百 KB大通常 10MB~30MB取决于模块插件系统自动加载 .so 插件需手动 import 插件并编译进最终二进制许可证LGPL 下可动态链接LGPL 下需提供目标文件或开放 relink 权限调试时替换换 .so 即可需重新编译完整应用我的项目选择了 gpl 授权模块所以静态链接没有许可证阻碍但如果你做的是闭源商业项目必须把 Qt 的许可证合规问题提前和法务确认好尤其是 QML 和部分插件模块。2. 搭建交叉编译环境工具链、Sysroot、环境变量全攻略静态交叉编译的第一块绊脚石就是环境。很多人按网上的教程装完工具链直接 ./configure结果 configure 要么找不到编译器要么在检测 sysroot 的时候崩溃——问题几乎都出在“工具链不匹配”和“缺少系统根目录”这两件事上。2.1 选择合适的工具链aarch64 的交叉编译工具链选择不少但我实测下来优先级大概是这样的Ubuntu/Debian 自带的gcc-aarch64-linux-gnu版本够新9.3/10.xapt 装完即用适合快速验证。ARM 官网的 GNU-A 系列工具链gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu版本明确符号齐全适合企业化项目锁定版本。Linaro 老版本工具链7.x很多工控板子上的 BSP 可能还在用注意 glibc 版本兼容性。我这次用的宿主机是 Ubuntu 18.04 虚拟机直接安装了gcc-aarch64-linux-gnu和g-aarch64-linux-gnu。如果你在 Ubuntu 20.04/22.04 上包名同样适用sudo apt update sudo apt install -y gcc-aarch64-linux-gnu g-aarch64-linux-gnu \ build-essential crossbuild-essential-arm64 \ libncurses5-dev装完后验证aarch64-linux-gnu-gcc --version aarch64-linux-gnu-g --version这里有个容易踩的坑Qt 的 configure 脚本会对编译器做一系列运行测试如果宿主机上没装libc6-dev-arm64-cross这类交叉运行库部分特性检测会返回“失败”。解决办法是安装完整依赖或者干脆给 configure 传入明确的平台选项让它跳过部分 autotest。2.2 准备 SysrootSysroot 是交叉编译的“虚拟根目录”里面放着目标机上必须的lib、usr/lib、usr/include但是架构必须是 aarch64 的。简单说有了正确的 sysroot你的交叉编译器在链接 libc 和内核头文件时才会从 sysroot 里找而不是用宿主机/usr/lib/x86_64-linux-gnu下的文件。获取 sysroot 的方法有两种我都试过方法一直接从开发板或设备镜像里拉。把板子上的/lib、/usr/lib、/usr/include用 tar 打包后拷到宿主机解压到~/sysroot-arm64。这种方式最接近目标环境依赖版本百分百匹配。方法二在宿主机上安装libc6-dev-arm64-cross系统会自动生成/usr/aarch64-linux-gnu目录。这个目录本身就能当 sysroot 用但需要额外处理一下符号链接sudo apt install libc6-dev-arm64-cross linux-libc-dev-arm64-cross mkdir -p ~/sysroot-arm64 sudo cp -r /usr/aarch64-linux-gnu/* ~/sysroot-arm64/ sudo cp -r /usr/include/aarch64-linux-gnu/* ~/sysroot-arm64/usr/include/ sudo ln -s . ~/sysroot-arm64/usr/aarch64-linux-gnu注意Qt configure 在检查 sysroot 时还要求/lib和/usr/lib下存在 ld-linux-aarch64.so.1所以确保ls ~/sysroot-arm64/lib/ld-linux-aarch64.so.1如果缺失从板子上拷贝或用find /usr/aarch64-linux-gnu -name ld-linux*找出来再软链进去。2.3 集中管理环境变量交叉编译最忌讳的就是“环境变量散落各终端”。我在项目里写了一个env-cross.sh每次编译前 source 一下保证所有子进程拿到一致的参数export ARCHarm64 export CROSS_COMPILEaarch64-linux-gnu- export SYSROOT$HOME/sysroot-arm64 export PATH/usr/bin:$PATH export CC${CROSS_COMPILE}gcc export CXX${CROSS_COMPILE}g export AR${CROSS_COMPILE}ar export AS${CROSS_COMPILE}as export LD${CROSS_COMPILE}ld export STRIP${CROSS_COMPILE}strip export RANLIB${CROSS_COMPILE}ranlib export OBJCOPY${CROSS_COMPILE}objcopy export PKG_CONFIG_PATH$SYSROOT/usr/lib/aarch64-linux-gnu/pkgconfig:$SYSROOT/usr/lib/pkgconfig export PKG_CONFIG_ALLOW_CROSS1 export PKG_CONFIG_SYSROOT_DIR$SYSROOT # Qt 相关 export QT_HOST_PREFIX$HOME/qt5-host export QT_TARGET_PREFIX/opt/qt5142这里的QT_HOST_PREFIX是宿主机上用来跑交叉编译工具的 Qt 基础目录后面会用到。先记住一个原则交叉编译时所有 --prefix 指向的都是目标设备上的路径不是宿主机路径。很多教程把 prefix 写成了宿主机的/usr/local/qt5结果编译出来的应用在板子上到处找/usr/local/qt5/...这就是典型翻车。3. 手工编译基础依赖所有第三方库都要过一遍交叉编译Qt 静态编译面临的第二个大头是第三方库。虽然 Qt 自带了不少 bundled 库zlib、libpng、libjpeg 等可以由 configure 决定是否编译但在嵌入式项目里我更倾向于手动编译核心依赖理由有三可以精简体积不用 qt 自带的带 debug 符号的中间产物strip 更干净可以锁定版本安全补丁升级时只重编某个依赖不必全量重编 Qt方便设置 feature比如 OpenSSL 的no-asm或优化选项Qt 内部 build 不一定暴露。我这次手动编译的依赖包括zlib、openssl、sqlite3、libpng后面发现 Qt 的 libpng 检测有点烦干脆手动编了、libjpeg-turbo 可选。编译每个库前都要在 env 前确认CC、SYSROOT已经生效。3.1 zlib基础中的基础zlib 体积小编译很快建议放第一个wget https://zlib.net/zlib-1.2.11.tar.gz tar xzf zlib-1.2.11.tar.gz cd zlib-1.2.11 export CFLAGS--sysroot$SYSROOT -O2 ./configure --prefix$SYSROOT/usr --static make -j$(nproc) make install这里有个细节zlib 的 configure 脚本默认会用cc要确保CC环境变量已经指向交叉编译器。如果出现Could not load shared library symbols之类的错误通常是 CFLAGS 里的 sysroot 没写对。3.2 OpenSSL如果需要 HTTPSQtNetwork 如果开了 TLS依赖 OpenSSL。先编译静态库wget https://www.openssl.org/source/old/1.1.1/openssl-1.1.1l.tar.gz tar xzf openssl-1.1.1l.tar.gz cd openssl-1.1.1l ./Configure linux-aarch64 --prefix/usr \ --openssldir/usr/ssl \ no-shared no-tests \ --cross-compile-prefix${CROSS_COMPILE} \ -fPIC make -j$(nproc) CC${CC} make install DESTDIR$SYSROOT重点解释--prefix/usr这是为了让 Qt 编译时在目标设备路径/usr/lib下找 libssl.a。后面的DESTDIR$SYSROOT指定安装到 sysroot 里但生成的库内的路径信息仍是/usr。如果不这么做Qt 的 configure 检测到 OpenSSL 路径和 sysroot 不一致经常直接返回“不支持”。编译完检查ls $SYSROOT/usr/lib/libssl.a $SYSROOT/usr/lib/libcrypto.a3.3 SQLite、libpng、libjpegSQLite 用默认的 autoconf 流程即可./configure --hostarm-linux-gnueabihf --prefix/usr \ --disable-shared --enable-static \ CC${CC} CFLAGS--sysroot$SYSROOT -O2 make -j$(nproc) make install DESTDIR$SYSROOTlibpng 需要 zlib 头文件在位编译时确认CPPFLAGS和LDFLAGS都带 sysroot 和 zlib 路径./configure --hostaarch64-linux-gnu --prefix/usr \ --disable-shared --enable-static \ CPPFLAGS--sysroot$SYSROOT -I$SYSROOT/usr/include \ LDFLAGS--sysroot$SYSROOT -L$SYSROOT/usr/lib make -j$(nproc) make install DESTDIR$SYSROOT为避免第三方库反复出现“找不到文件”的问题我把编译产物的检查命令固化到脚本里每次编完都跑一下for f in $SYSROOT/usr/lib/libz.a $SYSROOT/usr/lib/libssl.a $SYSROOT/usr/lib/libcrypto.a \ $SYSROOT/usr/lib/libsqlite3.a $SYSROOT/usr/lib/libpng.a; do [ -f $f ] echo OK: $f || echo MISSING: $f done当依赖库全齐后再进入 Qt 本身的构建。4. 编译 Qt5.14.2 本体configure、mkspecs 和 make install 的完整过程Qt 交叉编译的大头在这里。我见过不少人在 configure 这步反复失败其实大部分都离不开三个原因mkspec 不对、工具链变量没传给 configure、依赖路径不一致。把这三点理清Qt 其实没那么难啃。4.1 准备 mkspecQt 源码包里自带linux-aarch64-gnu-g的 mkspec位于qtbase/mkspecs/linux-aarch64-gnu-g多数情况下可以直接用。但我在 Ubuntu 18.04 上发现它的默认工具名是aarch64-linux-gnu-g和我装的一致所以直接指定-xplatform linux-aarch64-gnu-g就能用。如果你的工具链前缀不是标准前缀最好复制一份 mkspec 改一下cp -r qtbase/mkspecs/linux-aarch64-gnu-g qtbase/mkspecs/linux-arm64-mycustom # 编辑 qmake.conf我把 mkspec 里的工具链部分做成了这样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_OBJCOPY aarch64-linux-gnu-objcopy QMAKE_STRIP aarch64-linux-gnu-strip注意QMAKE_AR后面加cqs这种参数是为了让静态库合并时能递归插入避免 Qt 内部链接插件时出现符号找不到。4.2 configure 参数详解我最终的 configure 命令如下这个组合在 Qt 5.14.2 上实测可以完整走通cd qt-everywhere-src-5.14.2 mkdir -p build-arm64 cd build-arm64 ../configure \ -release \ -static \ -opensource \ -confirm-license \ -prefix /opt/qt5142 \ -xplatform linux-aarch64-gnu-g \ -sysroot $SYSROOT \ -nomake examples \ -nomake tests \ -skip qtwebengine \ -skip qtdeclarative \ -skip qtquickcontrols2 \ -no-opengl \ -no-eglfs \ -no-feature-vulkan \ -no-feature-librarymanager \ -qt-zlib \ -qt-libpng \ -qt-libjpeg \ -qt-pcre \ -qt-harfbuzz \ -openssl-linked \ -no-dbus \ -no-glib \ -no-icu \ -no-cups \ -no-xcb \ -no-wayland \ -no-linuxfb \ -no-kms \ -no-gstreamer \ -no-pulseaudio \ -no-alsa \ -no-tslib对照实际项目解读一下几个关键参数-static核心要求锁定静态编译-xplatform linux-aarch64-gnu-g交叉平台 mkspec必须和工具链匹配-sysroot $SYSROOT告诉 configure 去 sysroot 找目标系统的库和头文件-qt-zlib / -qt-pcre / -qt-harfbuzz用 Qt 自带的源码编译这些基础库省去外部依赖版本匹配问题前提是对体积不敏感-openssl-linked动态/静态链接 OpenSSL这里是静态编译 Qt所以必然要链接 .a 库。如果 OpenSSL 路径不对configure 会提示“OpenSSL disabled”务必回头查第 3 小节的 OpenSSL 安装-no-icu去掉 ICU 能大幅减小体积但 QML 的某些文本处理会受限。我项目只用 Widgets所以无所谓。如果你要跑 QML 且要国际文本最好保留 ICU。4.3 实际执行构建configure 成功后耐心等它输出 summary确认这些关键项都符合预期Build ..................: static Architecture ............: arm64 OpenSSL .................: yes ICU .....................: no Qt Network ..............: yes Qt Sql ..................: yes然后开始编译make -j$(nproc) make install这里需要提示静态编译的 Qt 会比动态编译慢不少实测在 8 核虚拟机上编译整个 qtbase qtdeclarative因为默认还是编译 QtWidgets 等基础模块大概 20~30 分钟。如果中途报错先别急着重跑把错误信息贴进终端往下翻大多数问题在config.log里可以找到根因。4.4 Sysroot 与 prefix 的隐含义-prefix /opt/qt5142这个路径是目标设备上的安装路径。在静态链接场景下应用运行时不依赖这个目录里的 .so 文件所以 prefix 只要在编译时一致即可。但 Qt 的运行时库仍会编译出一些可执行文件比如 lrelease、qmake 等这些也会被装进 sysroot 里所以 install 之前要确认 sysroot 有写权限否则 make install 会失败。如果你希望进一步裁剪可以在 configure 里加-no-feature-*把用不到的 Qt 功能关掉但建议先默认编译完保证项目能跑通后再逐项裁剪避免一开始就陷入配置迷宫。5. 编写并交叉编译一个最小 Qt 静态应用走到这一步环境已经通了接下来是验证整个链条的关键写一个最简单的 Qt Widgets 程序用新编译的 Qt 静态库交叉编译再扔到板子上跑。5.1 工程文件写法// main.cpp #include QApplication #include QLabel int main(int argc, char *argv[]) { QApplication app(argc, argv); QLabel label(Hello aarch64 Qt Static); label.resize(320, 240); label.show(); return app.exec(); }# hello.pro QT core gui widgets CONFIG static TARGET hello TEMPLATE app SOURCES main.cpp关键点是.pro文件里的CONFIG static。它让 qmake 在链接阶段自动带上 Qt 静态库需要的额外标志比如-Wl,-Bstatic和-Wl,-Bdynamic的组合。如果你用的是 CMake这时候需要手动处理静态链接标志qmake 相对省心。5.2 用交叉 qmake 构建使用编译出来的 qmake 直接构建$SYSROOT/opt/qt5142/bin/qmake hello.pro make如果没有意外会生成一个可执行文件hello。检查它的架构信息file hello # 输出: hello: ELF 64-bit LSB executable, ARM aarch64, ...再检查动态依赖aarch64-linux-gnu-readelf -d hello | grep NEEDED如果是真正的静态 Qt 应用输出应该是空的或者只有libc.so.6、libm.so.6这类系统库。这是判断静态编译是否成功的最直观方式。5.3 在目标板上的运行验证把hello拷贝到板子上scp hello user192.168.1.100:/tmp/ ssh user192.168.1.100 chmod x /tmp/hello /tmp/hello正常情况下板子上不需要设置任何LD_LIBRARY_PATH直接就能跑。这个验证步骤务必保留它是整个工具链和 sysroot 配置正确性的最终裁判。如果你习惯用 CMake构建步骤类似但链接参数要补充静态 Qt 的特殊要求我在第 7 节还会补充说明。6. 静态链接相关的深坑从链接顺序到插件导入静态编译不可能一帆风顺。我把常见问题和排查逻辑整理了一下这里挑几个最有代表性的展开讲。6.1 经典错误undefined reference to glXGetProcAddress 等这类错误通常出现在 Qt GUI 模块链接时。原因很直接QtGui 在配置时检测到系统有 X11 相关库于是把 X11 支持编了进去但你的交叉链接器找不到 X11 的静态库或参数顺序不对。解决思路是绕开 X11如果你的板子没有 X Serverconfigure 时增加-no-xcb -no-xcb-xlib -no-xkbcommon -no-xinput2或者改用-no-feature-x11再不行检查libX11.a和libxcb.a是否在 sysroot 的/usr/lib/aarch64-linux-gnu下。6.2 插件不会自动加载如何把插件链接进可执行文件动态 Qt 靠运行时扫描插件目录加载字体引擎、平台插件比如 linuxfb和 imageformats。但静态 Qt 不会自动扫描你必须显式地把需要的插件编进二进制里并在 main 函数里调用Q_IMPORT_PLUGIN或使用静态插件宏。最常用的平台插件是linuxfbLinux framebuffer在 .pro 里这样设置QTPLUGIN qlinuxfb对于 CMake需要这样手动处理target_link_libraries(hello PRIVATE Qt5::Widgets Qt5::Gui Qt5::Core ${QT_STATIC_PLUGINS} # 由 qmake 或 Qt 的 CMake 模块导出的变量 )如果你只做一个 CLI 工具不需要 GUI这一步可以忽略但绝大多数嵌入式项目都要 framebuffer 或 eglfs所以建议在初版就把插件链接逻辑跑通。6.3 链接顺序导致的“幽灵符号”静态链接对库的顺序极其敏感。qmake 生成链接命令时通常会把 Qt 的库放在后面但依赖 Qt 的第三方静态库如果顺序排在 Qt 之前链接器会找不到相关符号。典型报错/usr/bin/ld: cannot find -lQt5Widgets // 或者 undefined reference to QWidget::setWindowTitle(QString const)这类错误的排查链路确认libQt5Widgets.a真的存在于$SYSROOT/opt/qt5142/lib/检查 qmake 使用的QMAKE_LIBS_QT变量是否包含全部依赖库如果用了外部库如上文手动编译的 zlib把它放到 Qt 库前面。我把这步的检查固化成一条命令$SYSROOT/opt/qt5142/bin/qmake -query aarch64-linux-gnu-g -o hello *.o $SYSROOT/opt/qt5142/lib/libQt5Widgets.a ...如果哪一步出现 ld 错误再根据缺失符号逐步补齐库依赖。大部分时候没有捷径就是耐心看清单。6.4 运行时报错Qt 库版本不匹配有时编译成功把二进制拷贝到板子后却报This application failed to start because no Qt platform plugin could be initialized.静态 Qt 的常见原因是插件没有导入解决办法参考 6.2。如果确认导入了检查你是否把linuxfb插件编译进去了并确认 configure 时没有加-no-linuxfb。如果只留了minimal插件也会有类似问题。6.5 外部第三方静态库导致的内存或版本冲突如果你在项目里同时链接了自定义的libcurl.a而它内部也依赖libssl.a可能会和 Qt 链接的 OpenSSL 模块重复。虽然静态链接会去重但不同编译选项比如 PIC vs 非 PIC、debug vs release可能导致符号冲突。遇到这种情况我建议把项目里所有第三方库统一用同一套CFLAGS和交叉工具链编译不要混用系统自带和源码自编译的版本。这个教训我是在一次编译崩溃中实实在在踩到的宿主机自带的 libssl 是 x86_64 的我一时大意没加 DESTDIR导致 sysroot 里混入了一个 x86 的 .a链接时 Qt 通过Found /usr/lib/libssl.a找到它最终在板子上跑出各种内存越界排查了整整三天才定位到。7. 构建完成后的实际产物分析与体积优化静态链接的最终产品是一个体积动辄 20MB~30MB 的 ELF。这在嵌入式设备上可能不够友好所以构建完成后还得做一轮分析和优化。7.1 用 readelf 和 size 分析体积构成先看总大小和文件类型ls -lh hello file hello再分析哪些段占了多少空间aarch64-linux-gnu-size hello aarch64-linux-gnu-readelf -S hello | grep -E \.text|\.data|\.bss|\.rodata正常情况下.text是最大的紧随其后的是.rodata。如果你的.rodata巨大多半是引入了大量静态字符串比如 QML 编译产生的元对象信息可以考虑关掉不需要的 Qt 特性。7.2 strip 瘦身最直接的手段是用交叉 strip 去掉符号信息aarch64-linux-gnu-strip --strip-unneeded hello如果 strip 后体积下降不明显说明二进制里可能还有 debug 段可以在 Qt configure 时加-release已经加了或者在链接应用时加-s参数。我实测一个包含 QtWidgets、QtNetwork、QtSql 的静态应用strip 前 28MBstrip 后降到 16MB 左右效果还是很明显的。7.3 模块裁剪对体积的影响如果在项目需求允许的情况下尽量少依赖 QML 和 WebEngine。QtWebEngine 是体积黑洞5.14 上就算静态编译也基本百 MB 级建议直接-skip qtwebengine。如果只用 Widgets配合以下 configure 裁剪最终体积能控制在一个相对实用的范围-no-feature-printdialog-no-feature-printer-no-feature-ftp-no-feature-dns-lookup-no-feature-udpsocket-no-feature-imageformat-plugins如果只用到 png/jpeg裁剪完重新 configure 会快很多因为 Qt 源码里有些模块就不再编译了。7.4 部署时还需要注意的运行时目录即使静态编译Qt 在运行时仍可能查找某些路径比如/opt/qt5142/plugins或qt.conf指定的插件路径/opt/qt5142/translations用于国际化文件/opt/qt5142/qmlQML 场景下必须存在。对于 Widgets 程序只要正确编译了静态插件可以不带 plugins 目录但建议在可执行文件同目录放一个qt.conf内容很简却能在关键时刻避免平台插件初始化失败[Paths] Prefix ./ Plugins ./plugins Translations ./translations这样一来即使你忘了编译插件运行时也会去相对路径下找日志里报错更清楚。7.5 目标板上的测试清单部署到正式板之前我习惯跑一遍这个清单不带任何动态库直接拷贝执行执行后弹出窗口正常Linux fb 环境下画面显示无花屏执行后退出码为 0无relocation truncated to fit之类的警告连续运行 24 小时无内存异常增长重点排查第三方库的静态资源释放问题使用time统计启动耗时静态 Qt 的启动通常比动态库快因为省去了加载几十个 .so 的过程。拿到这份验证结果整个静态交叉编译链路才算真正跑通。8. 反复试错后的个人经验总结整个 Qt5.14.2-aarch64 静态交叉编译过程我最大的感受是这活儿不难但必须按顺序来。先把工具链、sysroot 搞正确再把第三方库逐个编好最后才碰 configure。官方文档其实把 80% 的选项都写清楚了但真正让人卡壳的往往是那些文档里默认“你已经知道”的东西——比如 sysroot 里的符号链接、prefix 与 DESTDIR 的配合、QTPLUGIN 的手动导入。几个值得反复提醒自己的点编译前用env检查CC、CXX、SYSROOT是否真的生效不要想当然用单独的 build 目录绝对不要在源码目录里直接跑 configure否则后续想换个参数重新编译会非常痛苦把每次 configure 的输出 summary 存成文件出问题能回溯静态链接关闭了插件自动发现机制平台插件、字体插件、图像格式插件都要你亲手“搬”进二进制里这个坑每个人都会踩早点把它写进项目检查清单里。另外关于 Qt 5.14.2 这个版本本身如果设备上没有硬性要求使用更新的 Qt我个人强烈建议锁定它。5.14.2 是新旧构建系统交替前最后一个稳定节点qmake 行为和依赖检测都相对可预期。换到 Qt 6.x aarch64 静态编译又会是另一套 CMake 逻辑、另一批 mkspec 兼容问题至少现阶段想快速产出一个能在 ARM64 工控设备上稳定运行的单一二进制Qt 5.14.2 aarch64 静态交叉编译是性价比极高的一条路。最后分享一个小技巧交叉编译的应用在板子上万一遇到崩溃先别急着上 gdb。在宿主机用aarch64-linux-gnu-objdump -d hello dis.txt把反汇编导出再对照板子上dmesg里的 PC 寄存器地址能快速定位崩溃函数。Qt 源码编译时默认不剥离所以符号虽然被 strip 掉了但地址范围还是能帮你找到所属函数这一步能省下大量在板子上调试的时间。
