先说明一下刚在RK3568这块板子上把一套界面程序从“开发机调通”到“目标板部署”整完踩了一路的坑。最终方案敲定为Qt5.14.2 aarch64静态交叉编译也就是把Qt整个编译成aarch64下的静态库然后在x86主机上写代码、交叉编译出单一可执行文件直接拷到板卡上运行。这套流程如果你正好也要做那这份从零开始的实操手册应该能帮你省掉一周的折腾时间。这篇手册适合谁看说得直白点手里有一块基于aarch64架构的ARM开发板或工控机比如RK3399、RK3568、树莓派4这类打算用Qt写带界面的应用程序同时希望最终产物别带一堆.so、别依赖目标板上有完整的Qt运行环境。如果你是这种场景下面这套完整流程可以直接照着做。我不光讲命令还会把每个关键参数为什么这么配、每个坑长什么样都拆开讲清楚。1. 整体设计思路拆解1.1 为什么偏偏是Qt 5.14.2 aarch64 静态交叉编译先把这套组合里几个关键词拆开看。Qt 5.14.2是2019年底发布的版本虽然是上一代LTS但到现在依然是很多嵌入式项目在用的主力版本原因很现实它在ARM平台上的资料最多、离线包最好找网上搜一个问题能翻出一堆案例不像5.15之后的源码包下载流程麻烦。更重要的是Qt 5.14.2对aarch64交叉编译的支持已经非常成熟官方就有现成的mkspec可以直接用。aarch64是ARM 64位指令集的标准称呼现在绝大多数新出的工业板卡、边缘计算盒子都是这个架构。做Qt界面通常绕不开它因为产品要跑界面、跑业务逻辑性能不能太弱。静态交叉编译这个概念分两层。交叉编译是在x86的PC上生成aarch64架构的机器码不用把编译环境搬到板子上静态则是把Qt库直接打包进最终的可执行文件里。三层组合在一起最终效果就是开发机上编译出一个单个的ELF可执行文件拷到目标板直接./app就能跑板子上既不需要安装Qt运行时也不需要设置库路径。我先说结论这套方案的部署体验是最舒服的没有之一。1.2 静态链接和动态部署我为什么选坑更少的那条路如果只是动态交叉编译流程其实更简单在x86主机上编译出aarch64的Qt动态库部署时把整个qt目录拷到板子上然后设置LD_LIBRARY_PATH程序运行时从指定路径加载.so。听着不难但实际项目里它会带来几个长期折磨人的问题动态部署每次都要把一堆.so同步到板子少拷一个程序就起不来。Qt的插件机制还会让事情更复杂platform插件、图片格式插件、字体插件各是一堆.so漏了一个就会出现毫无提示的黑屏或崩溃。板子上如果还跑着别的Qt程序大家共用一个Qt库目录升级一个应用可能导致另一个应用挂掉版本冲突排查起来非常痛苦。嵌入式产品的文件系统通常很小拷贝几十上百个文件本身就容易出错还占空间。静态编译完美避开了这些。最终产物就是一个自包含的可执行文件拷过去就能跑不干扰板子上的任何已有环境。缺点是编译时间更长、可执行文件更大还会涉及LGPL许可合规问题后面细说。但对大多数嵌入式Linux产品来说部署省心这个好处远大于体积大一点的成本。1.3 整体流程路线图整套搭建流程我用一个清单先说明白后面每一节都会展开讲准备编译主机环境安装aarch64交叉编译工具链准备sysroot目标系统的根目录文件获取Qt 5.14.2源码并处理第三方依赖配置Qt构建参数configure编译并安装Qt静态库编写测试程序验证静态链接部署到目标板并运行2. 编译环境与交叉工具链准备2.1 编译主机环境如何选这一步比你想的更重要很多第一次做交叉编译的人随手在一台最新的Ubuntu 24.04上开干结果编译出来的程序放到老一点的板子系统上直接报GLIBC版本错误。这个坑我在9.2小节专门展开讲这里先给结论编译主机的glibc版本最好是和你目标板系统的glibc版本一致或者更低。我自己用的是Ubuntu 20.04作为编译机目标板的系统基于Ubuntu 18.04构建glibc版本匹配度还算可以。如果你没有现成的老版本系统用一个Docker容器作为编译环境是最省事的等哪天需要重来容器删掉重新拉一个就行不会污染主系统。磁盘空间建议预留至少10GBQt全量静态编译的中间文件和产物都不小。内存8GB以上吧编译时多个并行任务还是挺吃内存的我就见过同事拿4GB内存的机器硬编最后swap吃满编译了六个小时。CPU方面核心数越多越好后面make -j参数会用到。主机上需要安装的基础工具链sudo apt update sudo apt install -y build-essential gcc-multilib g-multilib \ gcc-aarch64-linux-gnu g-aarch64-linux-gnu \ libc6-dev-arm64-cross \ wget tar xz-utils \ perl python3 flex bison这些包里gcc-aarch64-linux-gnu和g-aarch64-linux-gnu是交叉编译器本体libc6-dev-arm64-cross提供aarch64架构的标准C库头文件和库文件perl和python3是Qt构建系统的运行时依赖。2.2 交叉工具链三选一发版工具链、官方工具链、自己动手交叉工具链有几种选择我分别说一下使用感受。第一种是直接用系统仓库装的交叉工具链比如Ubuntu自带的gcc-aarch64-linux-gnu。优点是安装一条命令搞定和系统的其他工具兼容性好缺点是版本可能不是最新的。对构建Qt 5.14.2来说系统仓库版本完全够用这也是我推荐新手走的路。第二种是下载ARM官方工具链比如GNU Arm Toolchain。这类工具链通常做了不少嵌入式优化但它自带的sysroot可能和你目标板系统的库不一致移植时反而要多折腾一步。除非你的项目对编译器版本有硬性要求否则我建议先用系统自带的版本。第三种是自己从源码编译一个工具链。这个只适合有特殊需求的老手你要自己调gcc版本、binutils版本、glibc版本整个构建过程一两天都打不住对大多数人来说纯属浪费时间。工具链方案对比工具链来源安装难度与目标板一致性适合场景系统仓库低取决于目标板系统大多数项目首选ARM官方工具链中自带sysroot需自行适配对编译器版本有要求源码自编译高可控特殊定制场景安装完之后先验证一下工具链是否正常aarch64-linux-gnu-gcc --version aarch64-linux-gnu-g --version能正常打印版本号就说明交叉编译器已经可用。2.3 sysroot准备这是保证不跑偏的定海神针交叉编译里最容易出问题的一点就是编译器用错了头文件和库。aarch64-linux-gnu-gcc默认会去一个叫sysroot的目录里找这些文件所谓sysroot就是目标Linux系统根目录的镜像里面至少要有/lib、/usr/include、/usr/lib这些目录。交叉编译时编译器只从这个目录里找系统头文件和库不会去翻宿主机的/usr/include否则就会把x86的头文件混进来导致各种诡异报错。用apt装完交叉工具链后sysroot一般就在默认路径aarch64-linux-gnu-gcc --print-sysroot输出大概率是/usr/aarch64-linux-gnu。检查一下这个目录的关键内容ls /usr/aarch64-linux-gnu/lib/libc.a ls /usr/aarch64-linux-gnu/include/stdio.h对于静态编译libc.a必须存在它是静态链接C运行库的依赖。如果找不到说明没装libc6-dev-arm64-cross补装即可。为什么sysroot这么重要因为Qt的configure脚本在检测特性时需要交叉编译一堆小程序并运行它们或检查链接是否通过如果没有正确的sysroot检测就会误判。比如明明目标板没有OpenGLconfigure却检测到了宿主机x86的OpenGL库于是把OpenGL特性打开后续静态链接时就炸了。配置一个干净、明确的sysroot是避免这类“环境串味儿”问题的核心手段。3. Qt源码与第三方依赖怎么处理3.1 下载Qt 5.14.2源码并校验Qt源码的官方归档在download.qt.io5.14.2版本有两个选择qt-everywhere-src-5.14.2.tar.xz是全部模块的源码包包含Qt Charts、Qt WebEngine这些附加模块qtbase-everywhere-src-5.14.2.tar.xz只包含核心模块QtCore、QtGui、QtWidgets、QtNetwork、QtSql等正好覆盖常规界面开发需求。如果你是第一次走这套流程我强烈建议先从qtbase包开始它编译速度快、依赖少、不容易出幺蛾子。等qtbase这套流程跑通了再按需去加其他模块。wget https://download.qt.io/archive/qt/5.14/5.14.2/qtbase-everywhere-src-5.14.2.tar.xz tar xf qtbase-everywhere-src-5.14.2.tar.xz cd qtbase-everywhere-src-5.14.2下载完建议顺手做一下SHA256校验防止文件损坏。校验值在官网对应目录下能找到。3.2 哪些依赖库Qt自带别重复造轮子Qt 5.14.2的源码里自带了一批第三方库libpng、libjpeg、freetype、harfbuzz、sqlite、zlib都在里面。这意味着这些库你完全不用自己交叉编译只需要在configure时用-qt-开头的参数告诉Qt“用我自带的源码编译”。这就引出一个新手最常见的弯路先花大半天去交叉编译zlib、libpng、freetype然后再去编译Qt。其实没必要。Qt自带这些库的源码并且和Qt本身的版本做了适配直接跑configure让它自己编是最省事的。只有OpenSSL这种Qt不自带、但你又确实需要的库才值得手动交叉编译。我建议的依赖开关组合-qt-zlib -qt-libpng -qt-libjpeg -qt-freetype -qt-harfbuzz这几个参数合在一起的含义是zlib、libpng、libjpeg、freetype、harfbuzz全部使用Qt源码目录下的第三方库源码进行编译。好处是彻底绕开外部库的交叉编译问题坏处是Qt库体积会稍微大一点但对静态编译来说这个代价可以接受。如果后续要追求极致体积再考虑改用系统的静态库也不迟。3.3 真需要自己交叉编译的外部库OpenSSL场景如果你的程序要跑HTTPS、MQTT这类加密网络协议Qt的Network模块需要OpenSSL支持。但OpenSSL不在Qt源码包里需要单独交叉编译。这一步做起来不难但确实麻烦尤其是静态链接。先编译出aarch64的OpenSSL静态库wget https://www.openssl.org/source/openssl-3.0.8.tar.gz tar xzf openssl-3.0.8.tar.gz cd openssl-3.0.8 ./Configure linux-aarch64 \ --prefix/opt/aarch64-static-libs \ --cross-compile-prefixaarch64-linux-gnu- \ no-shared \ no-tests make -j$(nproc) make install这里no-shared是关键OpenSSL只会生成静态库libcrypto.a和libssl.a。然后在Qt的configure参数里加上-openssl-linked \ -I/opt/aarch64-static-libs/include \ -L/opt/aarch64-static-libs/libopenssl-linked表示把OpenSSL静态链接进QtNetwork库。如果你不需要网络加密直接在configure里写-no-openssl就行省掉一大堆麻烦。我的建议是暂不需要就先别加等真用到HTTPS了再重新编译Qt也比一开始就卡在OpenSSL上强。4. Configure参数配置与编译全流程4.1 一份可直接参考的完整configure命令configure是整个流程的核心参数直接影响最终Qt库的形态。下面这一份是我实际调通、验证可用的命令先完整贴出来再逐条解释每个参数为什么存在cd qtbase-everywhere-src-5.14.2 ./configure -prefix /opt/Qt5.14.2-static-aarch64 \ -opensource -confirm-license \ -release \ -static \ -platform linux-g \ -xplatform linux-aarch64-gnu-g \ -sysroot /usr/aarch64-linux-gnu \ -no-opengl \ -no-eglfs \ -no-dbus \ -no-icu \ -no-xcb \ -no-feature-printdialog \ -no-feature-printer \ -nomake examples \ -nomake tests \ -qt-zlib \ -qt-libpng \ -qt-libjpeg \ -qt-freetype \ -qt-harfbuzz这份配置面向的场景是无桌面环境的嵌入式Linux系统通过Linux Framebuffer直接显示Qt界面不需要X11不需要OpenGL不需要D-Bus。如果你的板子有GPU并且想用eglfs那需要调整参数这个我在4.3节单独说。4.2 平台参数三兄弟platform、xplatform、sysroot-platform、-xplatform、-sysroot这三个参数是最容易被新手搞混的我单独解释一下。-platform指定的是“运行Qt构建工具moc、uic、rcc、qmake”的主机平台。因为configure完之后Qt会先编译出一批小工具来帮助构建Qt本身这些工具最终是要在你当前的x86主机上运行的所以-platform必须填linux-g也就是用本机的g编译它们。-xplatform指定的是“最终Qt库的目标平台”这里填linux-aarch64-gnu-gQt就会调用aarch64-linux-gnu-gcc、aarch64-linux-gnu-g来编译aarch64架构的Qt库。这两个参数必须配合使用。有人图省事把-platform也写成linux-aarch64-gnu-g后果就是构建工具变成aarch64的可执行文件在x86主机上根本跑不起来configure会直接报错。-sysroot前面介绍过了告诉配置系统“目标板系统的根目录”在哪。这个参数能避免configure误读宿主机头文件非常重要建议显式指定。4.3 QPA平台插件怎么选直接决定configure的开关QPA是Qt的窗口系统抽象层简单理解就是“Qt图形应用运行在什么显示后端上”。动态编译时各种平台插件会以.so形式放在Qt的plugins目录里运行时动态加载静态编译时插件不能动态加载必须在编译阶段把需要的QPA插件嵌进Qt库里。所以要在configure参数里明确放出哪些QPA后端的开关。当前嵌入式场景主要有三个选择LinuxFB直接写/dev/fb0这个Linux帧缓冲设备不需要X11、不需要GPU最通用也最简单。它是Qt自带插件配置时不需要额外装系统库适合等级高的嵌入式板卡。上面那份命令默认会把linuxfb编译出来。EGLFS如果板子有Mali、PowerVR这样的GPU可以用eglfs后端走GPU渲染界面性能更好。但它依赖EGL/OpenGL ES头文件和库需要在sysroot中有对应的驱动库。我上面的命令用-no-eglfs把它关掉了因为大多数先用LinuxFB跑通流程的人暂时不需要GPU渲染。XCB如果你的目标板其实跑的是一个完整的Linux桌面环境比如X11那就需要xcb后端。但xcb的依赖很重需要xcb、xkbcommon、x11等一堆库的交叉静态版本我自己都很少在嵌入式环境里用它。不需要X11桌面就直接-no-xcb关掉。确认configure后到底内嵌了哪些QPA后端去生成的config.summary里查QPA backends一行有linuxfb就算成功。4.4 编译安装的时间预期与常见卡点configure完成后就可以正式编译了。这一步是最耗时的同时在多核机器上并行编译可以显著缩短时间make -j$(nproc)如果你的机器内存不大建议-make -j4甚至-j2避免并行编译内存吃紧。用qtbase包的话8核机器一般在20~40分钟左右就能编完。如果编译到一半因为某个模块报错中断先看看报错内容如果是缺少系统头文件或库对照前面环境准备补装后重新make即可。编译通过后执行安装make install安装后的Qt目录会在/opt/Qt5.14.2-static-aarch64下里面bin目录放的是qmake、moc这些工具lib目录放的是libQt5Core.a这种静态库。这一步出问题最多的是权限如果/opt目录你没有写权限先sudo chown一下目录所有权或者把-prefix换成你自己家目录的路径比如$HOME/Qt5.14.2-static-aarch64。4.5 用-skip参数减少无谓模块大幅缩短编译时间如果你用了qt-everywhere-src全量源码包而不是qtbase那configure时一定要用-skip参数跳过一批你不会用到的重型模块。最典型的元凶是qtwebengine这个模块是Chrome内核的封装编译一次以小时为单位并且嵌入式交叉编译成功率非常低。我通常会跳过这些模块-skip qtwebengine \ -skip qtwebview \ -skip qtcharts \ -skip qtdatavis3d \ -skip qtgamepad \ -skip qtlocation \ -skip qtsensors \ -skip qtserialbus \ -skip qtspeech选哪些skip取决于你的项目真正需要什么。如果只用Widgets、Core、Gui、Network这几个模块skip清单可以拉得再长一点。这样可以明显加快整个构建速度也少了一堆潜在编译错误。5. 交叉编译测试程序并到板子上跑通5.1 写一个最小的Qt Widgets程序并用qmake构建在/opt/Qt5.14.2-static-aarch64/bin下的qmake就是我们这台编译机生成出的aarch64版本的qmake。用它来为测试工程生成Makefile。新建一个目录放两个文件hello.proQT widgets TARGET hello TEMPLATE app SOURCES main.cppmain.cpp#include QApplication #include QLabel int main(int argc, char *argv[]) { QApplication app(argc, argv); QLabel label(Hello aarch64 Qt); label.resize(320, 160); label.show(); return app.exec(); }然后编译export PATH/opt/Qt5.14.2-static-aarch64/bin:$PATH qmake hello.pro make这里有个细节qmake是aarch64版的qmake但它是在x86主机上运行的Windows/Linux程序。你跑qmake hello.pro这一步是x86上运行的perl/工具脚本构建系统生成的Makefile已经带上了aarch64交叉编译器。直接make编译器就会是aarch64-linux-gnu-g。如果一切顺利会生成一个hello可执行文件。5.2 如何确认产物真的静态链接了这一步一定要做防止自我感觉良好。用file命令看一下交付物的架构和链接方式file hello如果输出长这样就说明Qt库已经静态打包进去了hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, with debug_info, not stripped看到statically linked几个字就说明Qt部分是静态的。但要注意glibc如果没有做全静态ldd仍会显示依赖libc.so.6和libstdc.so.6这其实是正常现象。在静态Qt库的场景下我们通常只静态Qt和第三方库glibc和libstdc保持动态以避开静态glibc的一系列问题。如果追求完全没有任何动态依赖可以给qmake加QMAKE_LFLAGS -static但那会引入DNS解析等麻烦一般情况下不建议。再确认一下QPA插件确实内嵌aarch64-linux-gnu-strings hello | grep linuxfb能搜到linuxfb字样就放心了。5.3 主机上先用qemu跑一把没有板子也能初步验证交叉编译出的程序不一定非要马上拷到硬板子上可以先用qemu-user在主机上模拟器跑一下验证逻辑层面没问题sudo apt install qemu-user-static qemu-aarch64 -L /usr/aarch64-linux-gnu ./hello -platform offscreen-L参数指定模拟的系统根目录为交叉工具链的sysroot这样程序运行需要的动态库都能找到。-platform offscreen是因为在qemu环境中没有真实的/dev/fb0设备用offscreen后端可以运行Qt程序但不真正显示窗口。如果程序没有立刻崩溃退出说明基本的Qt库初始化没问题。这个小技巧能帮你把构建问题、运行环境问题在发板之前就过滤掉一大半省不少事。5.4 部署到aarch64板子上注意字体和显示后端板子和开发机在同一局域网时直接用scp把可执行文件拷过去scp ./hello root板子IP:/root/然后SSH到板子执行./hello -platform linuxfb如果屏幕上没反应检查一下/dev/fb0是否存在ls -l /dev/fb0有些板子的内核没开帧缓冲设备或者当前用户没有访问权限用root跑或许就正常了。还有个几乎必踩的坑嵌入式板卡文件系统里通常没有中文字体。如果你程序里显示的是中文会看到一排方块。拷贝一个字体文件到板子上运行时指定字体目录mkdir -p /usr/share/fonts/truetype # 从主机拷贝字体 scp wqy-microhei.ttc root板子IP:/usr/share/fonts/truetype/ # 板子上运行 QT_QPA_FONTDIR/usr/share/fonts/truetype ./hello -platform linuxfb这里wqy-microhei.ttc是文泉驿微米黑字体免费开源的中文字体具体文件名看你从哪获取字体文件。5.5 可执行文件体积太大怎么办先strip再考虑裁剪静态链接一个Qt Widgets应用产物体积通常在20MB到40MB之间这是正常现象。先用strip把符号表剥了体积能降一截aarch64-linux-gnu-strip hello接下来如果还想缩就得从Qt configure的裁剪特性入手。-no-feature-*系列参数可以关闭具体功能比如不需要打印对话框就关掉不需要拖拽就关掉把程序里用不到的Qt功能尽量排除。但这里要小心别为了体积把程序需要的基础功能也关了。我一般的次序是先strip体积还嫌大再逐个加-no-feature参数每加一个就编译跑一遍测试程序确认功能没缺。6. 常见问题与排查技巧实录6.1 高频错误速查表配置和编译阶段我自己在搭建过程中反复遇到过的问题整理成一张表报错/现象原因解决办法configure: Cannot run compiler g-platform或-xplatform配错检查-platform为linux-gxplatform为linux-aarch64-gnu-gsysroot目录找不到sysroot路径不存在或字母拼错用aarch64-linux-gnu-gcc --print-sysroot确认实际路径fatal error: bits/predefs.h: No such file or directorygcc和sysroot版本不匹配或sysroot缺失标准头文件确认交叉工具链和libc6-dev-arm64-cross都已安装cannot find -lGL有OpenGL相关模块未在configure里关闭加上-no-opengl重新configurecannot find -lxcb启用了xcb但sysroot里没有xcb静态库不需要X11就加-no-xcb需要就装xcb-dev的交叉包Project ERROR: Unknown module(s) in QT: quick编译的是qtbase包不包含Qt Quick模块改用qt-everywhere包或确认项目不需要Quick运行时报could not find or load the Qt platform plugin静态编译时qpa插件没有被编入检查config.summary里的QPA backends并重新configure6.2 GLIBC版本不匹配交叉编译里最大的坑这个坑我吃了好几次亏单拎出来重点说。你在Ubuntu 22.04或更高版本的系统上编译出的程序放到基于Ubuntu 18.04的板子系统上跑经常报这种错./hello: /lib/aarch64-linux-gnu/libc.so.6: version GLIBC_2.34 not found原因很简单编译机的glibc版本高于目标板的glibc版本编译器链接进程序的glibc符号版本在目标板上不存在。解决办法有几种。最推荐的是使用与目标板系统接近或更老的系统作为编译环境比如目标板是Ubuntu 18.04那就用Ubuntu 18.04或20.04的容器来编译。如果一定用比目标板新的系统可以考虑在configure时加上-static-libgcc -static-libstdc把C运行时也静态打包进去但仍无法解决glibc符号版本问题。所以构建环境越早固定越好最好用Docker封装。6.3 静态链接后程序跑不了缺少插件或字体静态编译完成后最容易栽在运行阶段的就是启动时找不到QPA插件。这个错误的经典面目是This application failed to start because no Qt platform plugin could be initialized. Available platform plugins are: offscreen, minimal.Available列表里如果连linuxfb都没有那说明configure阶段就没有把linuxfb后端编进去。回到configure命令确认没有误加-no-linuxfb确认config.summary里QPA backends有linuxfb然后重新编译。Available列表里有offscreen但没有linuxfb那就说明你板子上的/dev/fb0不可访问或者内核没开帧缓冲用root权限跑一遍排除权限问题。运行Qt程序时最容易被忽视的就是字体。Qt默认会去/usr/share/fonts、/usr/lib/fonts这样的标准路径找字体嵌入式文件系统里往往是空的。启动参数里用QT_QPA_FONTDIR指定你自己的字体目录或者干脆把字体文件放到系统标准目录都能解决。6.4 一个能帮你以后少走弯路的习惯把构建过程固化成脚本折腾完这一整套我最大的体会是这套编译流程不是一次性的很可能过三个月需求变了要重新编一次。到时候你是重新回忆还是看脚本我建议把整个configure和make步骤写成一个shell脚本放到Qt源码目录旁边。下次要重新构建跑一下脚本就能复现环境。更进一步如果用了Docker把整个工具链、sysroot、Qt编译环境打进镜像里以后换机器也是同一个命令拉起彻底告别环境差异问题。脚本里至少保留这几个关键信息#!/bin/bash export PATH/opt/Qt5.14.2-static-aarch64/bin:$PATH ./configure -prefix /opt/Qt5.14.2-static-aarch64 \ -opensource -confirm-license \ -release -static \ -platform linux-g \ -xplatform linux-aarch64-gnu-g \ -sysroot /usr/aarch64-linux-gnu \ -no-opengl -no-eglfs -no-dbus -no-icu -no-xcb \ -qt-zlib -qt-libpng -qt-libjpeg -qt-freetype -qt-harfbuzz \ -nomake examples -nomake tests make -j$(nproc) make install把环境变量、configure参数、make命令写清楚比任何文档都直观。6.5 关于LGPL合规的提醒Qt 5.14.2是LGPLv3/GPLv2双许可静态链接Qt库在商用分发场景下要注意LGPL条款要求如果你的程序动态链接Qt库那比较好办但静态链接意味着你把LGPL代码和你的代码打包在了一起就需要向接收方提供你程序的目标文件让接收方可以用它们替换静态链接的Qt库后重新链接。如果不想履行这个义务就得购买Qt商业授权。作为开发者这一步不搞清楚产品做大了可能惹上法律麻烦。虽然这属于许可问题不算技术问题但我觉得在静态Qt方案里必须提一句。写在最后一点实践心得整套Qt 5.14.2 aarch64静态交叉编译环境我从零搭完最想说的是不要怕configure那一大串参数每一个都是可解释的花一个小时把它们研究透后面能省一整天。我在实际项目里最后编译出来的界面程序大约28MB拷到板子上直接运行连环境变量都不用配这种感觉是真的舒服。另外如果手里暂时没有目标板强烈建议先在qemu里把程序跑通再发板这一步筛选掉的好多奇怪问题。等以后项目要支持触摸屏、要接GPU加速再回头改configure参数重新编译Qt整个流程你已经能完全掌控了。
先说明一下刚在RK3568这块板子上把一套界面程序从“开发机调通”到“目标板部署”整完踩了一路的坑。最终方案敲定为Qt5.14.2 aarch64静态交叉编译也就是把Qt整个编译成aarch64下的静态库然后在x86主机上写代码、交叉编译出单一可执行文件直接拷到板卡上运行。这套流程如果你正好也要做那这份从零开始的实操手册应该能帮你省掉一周的折腾时间。这篇手册适合谁看说得直白点手里有一块基于aarch64架构的ARM开发板或工控机比如RK3399、RK3568、树莓派4这类打算用Qt写带界面的应用程序同时希望最终产物别带一堆.so、别依赖目标板上有完整的Qt运行环境。如果你是这种场景下面这套完整流程可以直接照着做。我不光讲命令还会把每个关键参数为什么这么配、每个坑长什么样都拆开讲清楚。1. 整体设计思路拆解1.1 为什么偏偏是Qt 5.14.2 aarch64 静态交叉编译先把这套组合里几个关键词拆开看。Qt 5.14.2是2019年底发布的版本虽然是上一代LTS但到现在依然是很多嵌入式项目在用的主力版本原因很现实它在ARM平台上的资料最多、离线包最好找网上搜一个问题能翻出一堆案例不像5.15之后的源码包下载流程麻烦。更重要的是Qt 5.14.2对aarch64交叉编译的支持已经非常成熟官方就有现成的mkspec可以直接用。aarch64是ARM 64位指令集的标准称呼现在绝大多数新出的工业板卡、边缘计算盒子都是这个架构。做Qt界面通常绕不开它因为产品要跑界面、跑业务逻辑性能不能太弱。静态交叉编译这个概念分两层。交叉编译是在x86的PC上生成aarch64架构的机器码不用把编译环境搬到板子上静态则是把Qt库直接打包进最终的可执行文件里。三层组合在一起最终效果就是开发机上编译出一个单个的ELF可执行文件拷到目标板直接./app就能跑板子上既不需要安装Qt运行时也不需要设置库路径。我先说结论这套方案的部署体验是最舒服的没有之一。1.2 静态链接和动态部署我为什么选坑更少的那条路如果只是动态交叉编译流程其实更简单在x86主机上编译出aarch64的Qt动态库部署时把整个qt目录拷到板子上然后设置LD_LIBRARY_PATH程序运行时从指定路径加载.so。听着不难但实际项目里它会带来几个长期折磨人的问题动态部署每次都要把一堆.so同步到板子少拷一个程序就起不来。Qt的插件机制还会让事情更复杂platform插件、图片格式插件、字体插件各是一堆.so漏了一个就会出现毫无提示的黑屏或崩溃。板子上如果还跑着别的Qt程序大家共用一个Qt库目录升级一个应用可能导致另一个应用挂掉版本冲突排查起来非常痛苦。嵌入式产品的文件系统通常很小拷贝几十上百个文件本身就容易出错还占空间。静态编译完美避开了这些。最终产物就是一个自包含的可执行文件拷过去就能跑不干扰板子上的任何已有环境。缺点是编译时间更长、可执行文件更大还会涉及LGPL许可合规问题后面细说。但对大多数嵌入式Linux产品来说部署省心这个好处远大于体积大一点的成本。1.3 整体流程路线图整套搭建流程我用一个清单先说明白后面每一节都会展开讲准备编译主机环境安装aarch64交叉编译工具链准备sysroot目标系统的根目录文件获取Qt 5.14.2源码并处理第三方依赖配置Qt构建参数configure编译并安装Qt静态库编写测试程序验证静态链接部署到目标板并运行2. 编译环境与交叉工具链准备2.1 编译主机环境如何选这一步比你想的更重要很多第一次做交叉编译的人随手在一台最新的Ubuntu 24.04上开干结果编译出来的程序放到老一点的板子系统上直接报GLIBC版本错误。这个坑我在9.2小节专门展开讲这里先给结论编译主机的glibc版本最好是和你目标板系统的glibc版本一致或者更低。我自己用的是Ubuntu 20.04作为编译机目标板的系统基于Ubuntu 18.04构建glibc版本匹配度还算可以。如果你没有现成的老版本系统用一个Docker容器作为编译环境是最省事的等哪天需要重来容器删掉重新拉一个就行不会污染主系统。磁盘空间建议预留至少10GBQt全量静态编译的中间文件和产物都不小。内存8GB以上吧编译时多个并行任务还是挺吃内存的我就见过同事拿4GB内存的机器硬编最后swap吃满编译了六个小时。CPU方面核心数越多越好后面make -j参数会用到。主机上需要安装的基础工具链sudo apt update sudo apt install -y build-essential gcc-multilib g-multilib \ gcc-aarch64-linux-gnu g-aarch64-linux-gnu \ libc6-dev-arm64-cross \ wget tar xz-utils \ perl python3 flex bison这些包里gcc-aarch64-linux-gnu和g-aarch64-linux-gnu是交叉编译器本体libc6-dev-arm64-cross提供aarch64架构的标准C库头文件和库文件perl和python3是Qt构建系统的运行时依赖。2.2 交叉工具链三选一发版工具链、官方工具链、自己动手交叉工具链有几种选择我分别说一下使用感受。第一种是直接用系统仓库装的交叉工具链比如Ubuntu自带的gcc-aarch64-linux-gnu。优点是安装一条命令搞定和系统的其他工具兼容性好缺点是版本可能不是最新的。对构建Qt 5.14.2来说系统仓库版本完全够用这也是我推荐新手走的路。第二种是下载ARM官方工具链比如GNU Arm Toolchain。这类工具链通常做了不少嵌入式优化但它自带的sysroot可能和你目标板系统的库不一致移植时反而要多折腾一步。除非你的项目对编译器版本有硬性要求否则我建议先用系统自带的版本。第三种是自己从源码编译一个工具链。这个只适合有特殊需求的老手你要自己调gcc版本、binutils版本、glibc版本整个构建过程一两天都打不住对大多数人来说纯属浪费时间。工具链方案对比工具链来源安装难度与目标板一致性适合场景系统仓库低取决于目标板系统大多数项目首选ARM官方工具链中自带sysroot需自行适配对编译器版本有要求源码自编译高可控特殊定制场景安装完之后先验证一下工具链是否正常aarch64-linux-gnu-gcc --version aarch64-linux-gnu-g --version能正常打印版本号就说明交叉编译器已经可用。2.3 sysroot准备这是保证不跑偏的定海神针交叉编译里最容易出问题的一点就是编译器用错了头文件和库。aarch64-linux-gnu-gcc默认会去一个叫sysroot的目录里找这些文件所谓sysroot就是目标Linux系统根目录的镜像里面至少要有/lib、/usr/include、/usr/lib这些目录。交叉编译时编译器只从这个目录里找系统头文件和库不会去翻宿主机的/usr/include否则就会把x86的头文件混进来导致各种诡异报错。用apt装完交叉工具链后sysroot一般就在默认路径aarch64-linux-gnu-gcc --print-sysroot输出大概率是/usr/aarch64-linux-gnu。检查一下这个目录的关键内容ls /usr/aarch64-linux-gnu/lib/libc.a ls /usr/aarch64-linux-gnu/include/stdio.h对于静态编译libc.a必须存在它是静态链接C运行库的依赖。如果找不到说明没装libc6-dev-arm64-cross补装即可。为什么sysroot这么重要因为Qt的configure脚本在检测特性时需要交叉编译一堆小程序并运行它们或检查链接是否通过如果没有正确的sysroot检测就会误判。比如明明目标板没有OpenGLconfigure却检测到了宿主机x86的OpenGL库于是把OpenGL特性打开后续静态链接时就炸了。配置一个干净、明确的sysroot是避免这类“环境串味儿”问题的核心手段。3. Qt源码与第三方依赖怎么处理3.1 下载Qt 5.14.2源码并校验Qt源码的官方归档在download.qt.io5.14.2版本有两个选择qt-everywhere-src-5.14.2.tar.xz是全部模块的源码包包含Qt Charts、Qt WebEngine这些附加模块qtbase-everywhere-src-5.14.2.tar.xz只包含核心模块QtCore、QtGui、QtWidgets、QtNetwork、QtSql等正好覆盖常规界面开发需求。如果你是第一次走这套流程我强烈建议先从qtbase包开始它编译速度快、依赖少、不容易出幺蛾子。等qtbase这套流程跑通了再按需去加其他模块。wget https://download.qt.io/archive/qt/5.14/5.14.2/qtbase-everywhere-src-5.14.2.tar.xz tar xf qtbase-everywhere-src-5.14.2.tar.xz cd qtbase-everywhere-src-5.14.2下载完建议顺手做一下SHA256校验防止文件损坏。校验值在官网对应目录下能找到。3.2 哪些依赖库Qt自带别重复造轮子Qt 5.14.2的源码里自带了一批第三方库libpng、libjpeg、freetype、harfbuzz、sqlite、zlib都在里面。这意味着这些库你完全不用自己交叉编译只需要在configure时用-qt-开头的参数告诉Qt“用我自带的源码编译”。这就引出一个新手最常见的弯路先花大半天去交叉编译zlib、libpng、freetype然后再去编译Qt。其实没必要。Qt自带这些库的源码并且和Qt本身的版本做了适配直接跑configure让它自己编是最省事的。只有OpenSSL这种Qt不自带、但你又确实需要的库才值得手动交叉编译。我建议的依赖开关组合-qt-zlib -qt-libpng -qt-libjpeg -qt-freetype -qt-harfbuzz这几个参数合在一起的含义是zlib、libpng、libjpeg、freetype、harfbuzz全部使用Qt源码目录下的第三方库源码进行编译。好处是彻底绕开外部库的交叉编译问题坏处是Qt库体积会稍微大一点但对静态编译来说这个代价可以接受。如果后续要追求极致体积再考虑改用系统的静态库也不迟。3.3 真需要自己交叉编译的外部库OpenSSL场景如果你的程序要跑HTTPS、MQTT这类加密网络协议Qt的Network模块需要OpenSSL支持。但OpenSSL不在Qt源码包里需要单独交叉编译。这一步做起来不难但确实麻烦尤其是静态链接。先编译出aarch64的OpenSSL静态库wget https://www.openssl.org/source/openssl-3.0.8.tar.gz tar xzf openssl-3.0.8.tar.gz cd openssl-3.0.8 ./Configure linux-aarch64 \ --prefix/opt/aarch64-static-libs \ --cross-compile-prefixaarch64-linux-gnu- \ no-shared \ no-tests make -j$(nproc) make install这里no-shared是关键OpenSSL只会生成静态库libcrypto.a和libssl.a。然后在Qt的configure参数里加上-openssl-linked \ -I/opt/aarch64-static-libs/include \ -L/opt/aarch64-static-libs/libopenssl-linked表示把OpenSSL静态链接进QtNetwork库。如果你不需要网络加密直接在configure里写-no-openssl就行省掉一大堆麻烦。我的建议是暂不需要就先别加等真用到HTTPS了再重新编译Qt也比一开始就卡在OpenSSL上强。4. Configure参数配置与编译全流程4.1 一份可直接参考的完整configure命令configure是整个流程的核心参数直接影响最终Qt库的形态。下面这一份是我实际调通、验证可用的命令先完整贴出来再逐条解释每个参数为什么存在cd qtbase-everywhere-src-5.14.2 ./configure -prefix /opt/Qt5.14.2-static-aarch64 \ -opensource -confirm-license \ -release \ -static \ -platform linux-g \ -xplatform linux-aarch64-gnu-g \ -sysroot /usr/aarch64-linux-gnu \ -no-opengl \ -no-eglfs \ -no-dbus \ -no-icu \ -no-xcb \ -no-feature-printdialog \ -no-feature-printer \ -nomake examples \ -nomake tests \ -qt-zlib \ -qt-libpng \ -qt-libjpeg \ -qt-freetype \ -qt-harfbuzz这份配置面向的场景是无桌面环境的嵌入式Linux系统通过Linux Framebuffer直接显示Qt界面不需要X11不需要OpenGL不需要D-Bus。如果你的板子有GPU并且想用eglfs那需要调整参数这个我在4.3节单独说。4.2 平台参数三兄弟platform、xplatform、sysroot-platform、-xplatform、-sysroot这三个参数是最容易被新手搞混的我单独解释一下。-platform指定的是“运行Qt构建工具moc、uic、rcc、qmake”的主机平台。因为configure完之后Qt会先编译出一批小工具来帮助构建Qt本身这些工具最终是要在你当前的x86主机上运行的所以-platform必须填linux-g也就是用本机的g编译它们。-xplatform指定的是“最终Qt库的目标平台”这里填linux-aarch64-gnu-gQt就会调用aarch64-linux-gnu-gcc、aarch64-linux-gnu-g来编译aarch64架构的Qt库。这两个参数必须配合使用。有人图省事把-platform也写成linux-aarch64-gnu-g后果就是构建工具变成aarch64的可执行文件在x86主机上根本跑不起来configure会直接报错。-sysroot前面介绍过了告诉配置系统“目标板系统的根目录”在哪。这个参数能避免configure误读宿主机头文件非常重要建议显式指定。4.3 QPA平台插件怎么选直接决定configure的开关QPA是Qt的窗口系统抽象层简单理解就是“Qt图形应用运行在什么显示后端上”。动态编译时各种平台插件会以.so形式放在Qt的plugins目录里运行时动态加载静态编译时插件不能动态加载必须在编译阶段把需要的QPA插件嵌进Qt库里。所以要在configure参数里明确放出哪些QPA后端的开关。当前嵌入式场景主要有三个选择LinuxFB直接写/dev/fb0这个Linux帧缓冲设备不需要X11、不需要GPU最通用也最简单。它是Qt自带插件配置时不需要额外装系统库适合等级高的嵌入式板卡。上面那份命令默认会把linuxfb编译出来。EGLFS如果板子有Mali、PowerVR这样的GPU可以用eglfs后端走GPU渲染界面性能更好。但它依赖EGL/OpenGL ES头文件和库需要在sysroot中有对应的驱动库。我上面的命令用-no-eglfs把它关掉了因为大多数先用LinuxFB跑通流程的人暂时不需要GPU渲染。XCB如果你的目标板其实跑的是一个完整的Linux桌面环境比如X11那就需要xcb后端。但xcb的依赖很重需要xcb、xkbcommon、x11等一堆库的交叉静态版本我自己都很少在嵌入式环境里用它。不需要X11桌面就直接-no-xcb关掉。确认configure后到底内嵌了哪些QPA后端去生成的config.summary里查QPA backends一行有linuxfb就算成功。4.4 编译安装的时间预期与常见卡点configure完成后就可以正式编译了。这一步是最耗时的同时在多核机器上并行编译可以显著缩短时间make -j$(nproc)如果你的机器内存不大建议-make -j4甚至-j2避免并行编译内存吃紧。用qtbase包的话8核机器一般在20~40分钟左右就能编完。如果编译到一半因为某个模块报错中断先看看报错内容如果是缺少系统头文件或库对照前面环境准备补装后重新make即可。编译通过后执行安装make install安装后的Qt目录会在/opt/Qt5.14.2-static-aarch64下里面bin目录放的是qmake、moc这些工具lib目录放的是libQt5Core.a这种静态库。这一步出问题最多的是权限如果/opt目录你没有写权限先sudo chown一下目录所有权或者把-prefix换成你自己家目录的路径比如$HOME/Qt5.14.2-static-aarch64。4.5 用-skip参数减少无谓模块大幅缩短编译时间如果你用了qt-everywhere-src全量源码包而不是qtbase那configure时一定要用-skip参数跳过一批你不会用到的重型模块。最典型的元凶是qtwebengine这个模块是Chrome内核的封装编译一次以小时为单位并且嵌入式交叉编译成功率非常低。我通常会跳过这些模块-skip qtwebengine \ -skip qtwebview \ -skip qtcharts \ -skip qtdatavis3d \ -skip qtgamepad \ -skip qtlocation \ -skip qtsensors \ -skip qtserialbus \ -skip qtspeech选哪些skip取决于你的项目真正需要什么。如果只用Widgets、Core、Gui、Network这几个模块skip清单可以拉得再长一点。这样可以明显加快整个构建速度也少了一堆潜在编译错误。5. 交叉编译测试程序并到板子上跑通5.1 写一个最小的Qt Widgets程序并用qmake构建在/opt/Qt5.14.2-static-aarch64/bin下的qmake就是我们这台编译机生成出的aarch64版本的qmake。用它来为测试工程生成Makefile。新建一个目录放两个文件hello.proQT widgets TARGET hello TEMPLATE app SOURCES main.cppmain.cpp#include QApplication #include QLabel int main(int argc, char *argv[]) { QApplication app(argc, argv); QLabel label(Hello aarch64 Qt); label.resize(320, 160); label.show(); return app.exec(); }然后编译export PATH/opt/Qt5.14.2-static-aarch64/bin:$PATH qmake hello.pro make这里有个细节qmake是aarch64版的qmake但它是在x86主机上运行的Windows/Linux程序。你跑qmake hello.pro这一步是x86上运行的perl/工具脚本构建系统生成的Makefile已经带上了aarch64交叉编译器。直接make编译器就会是aarch64-linux-gnu-g。如果一切顺利会生成一个hello可执行文件。5.2 如何确认产物真的静态链接了这一步一定要做防止自我感觉良好。用file命令看一下交付物的架构和链接方式file hello如果输出长这样就说明Qt库已经静态打包进去了hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, with debug_info, not stripped看到statically linked几个字就说明Qt部分是静态的。但要注意glibc如果没有做全静态ldd仍会显示依赖libc.so.6和libstdc.so.6这其实是正常现象。在静态Qt库的场景下我们通常只静态Qt和第三方库glibc和libstdc保持动态以避开静态glibc的一系列问题。如果追求完全没有任何动态依赖可以给qmake加QMAKE_LFLAGS -static但那会引入DNS解析等麻烦一般情况下不建议。再确认一下QPA插件确实内嵌aarch64-linux-gnu-strings hello | grep linuxfb能搜到linuxfb字样就放心了。5.3 主机上先用qemu跑一把没有板子也能初步验证交叉编译出的程序不一定非要马上拷到硬板子上可以先用qemu-user在主机上模拟器跑一下验证逻辑层面没问题sudo apt install qemu-user-static qemu-aarch64 -L /usr/aarch64-linux-gnu ./hello -platform offscreen-L参数指定模拟的系统根目录为交叉工具链的sysroot这样程序运行需要的动态库都能找到。-platform offscreen是因为在qemu环境中没有真实的/dev/fb0设备用offscreen后端可以运行Qt程序但不真正显示窗口。如果程序没有立刻崩溃退出说明基本的Qt库初始化没问题。这个小技巧能帮你把构建问题、运行环境问题在发板之前就过滤掉一大半省不少事。5.4 部署到aarch64板子上注意字体和显示后端板子和开发机在同一局域网时直接用scp把可执行文件拷过去scp ./hello root板子IP:/root/然后SSH到板子执行./hello -platform linuxfb如果屏幕上没反应检查一下/dev/fb0是否存在ls -l /dev/fb0有些板子的内核没开帧缓冲设备或者当前用户没有访问权限用root跑或许就正常了。还有个几乎必踩的坑嵌入式板卡文件系统里通常没有中文字体。如果你程序里显示的是中文会看到一排方块。拷贝一个字体文件到板子上运行时指定字体目录mkdir -p /usr/share/fonts/truetype # 从主机拷贝字体 scp wqy-microhei.ttc root板子IP:/usr/share/fonts/truetype/ # 板子上运行 QT_QPA_FONTDIR/usr/share/fonts/truetype ./hello -platform linuxfb这里wqy-microhei.ttc是文泉驿微米黑字体免费开源的中文字体具体文件名看你从哪获取字体文件。5.5 可执行文件体积太大怎么办先strip再考虑裁剪静态链接一个Qt Widgets应用产物体积通常在20MB到40MB之间这是正常现象。先用strip把符号表剥了体积能降一截aarch64-linux-gnu-strip hello接下来如果还想缩就得从Qt configure的裁剪特性入手。-no-feature-*系列参数可以关闭具体功能比如不需要打印对话框就关掉不需要拖拽就关掉把程序里用不到的Qt功能尽量排除。但这里要小心别为了体积把程序需要的基础功能也关了。我一般的次序是先strip体积还嫌大再逐个加-no-feature参数每加一个就编译跑一遍测试程序确认功能没缺。6. 常见问题与排查技巧实录6.1 高频错误速查表配置和编译阶段我自己在搭建过程中反复遇到过的问题整理成一张表报错/现象原因解决办法configure: Cannot run compiler g-platform或-xplatform配错检查-platform为linux-gxplatform为linux-aarch64-gnu-gsysroot目录找不到sysroot路径不存在或字母拼错用aarch64-linux-gnu-gcc --print-sysroot确认实际路径fatal error: bits/predefs.h: No such file or directorygcc和sysroot版本不匹配或sysroot缺失标准头文件确认交叉工具链和libc6-dev-arm64-cross都已安装cannot find -lGL有OpenGL相关模块未在configure里关闭加上-no-opengl重新configurecannot find -lxcb启用了xcb但sysroot里没有xcb静态库不需要X11就加-no-xcb需要就装xcb-dev的交叉包Project ERROR: Unknown module(s) in QT: quick编译的是qtbase包不包含Qt Quick模块改用qt-everywhere包或确认项目不需要Quick运行时报could not find or load the Qt platform plugin静态编译时qpa插件没有被编入检查config.summary里的QPA backends并重新configure6.2 GLIBC版本不匹配交叉编译里最大的坑这个坑我吃了好几次亏单拎出来重点说。你在Ubuntu 22.04或更高版本的系统上编译出的程序放到基于Ubuntu 18.04的板子系统上跑经常报这种错./hello: /lib/aarch64-linux-gnu/libc.so.6: version GLIBC_2.34 not found原因很简单编译机的glibc版本高于目标板的glibc版本编译器链接进程序的glibc符号版本在目标板上不存在。解决办法有几种。最推荐的是使用与目标板系统接近或更老的系统作为编译环境比如目标板是Ubuntu 18.04那就用Ubuntu 18.04或20.04的容器来编译。如果一定用比目标板新的系统可以考虑在configure时加上-static-libgcc -static-libstdc把C运行时也静态打包进去但仍无法解决glibc符号版本问题。所以构建环境越早固定越好最好用Docker封装。6.3 静态链接后程序跑不了缺少插件或字体静态编译完成后最容易栽在运行阶段的就是启动时找不到QPA插件。这个错误的经典面目是This application failed to start because no Qt platform plugin could be initialized. Available platform plugins are: offscreen, minimal.Available列表里如果连linuxfb都没有那说明configure阶段就没有把linuxfb后端编进去。回到configure命令确认没有误加-no-linuxfb确认config.summary里QPA backends有linuxfb然后重新编译。Available列表里有offscreen但没有linuxfb那就说明你板子上的/dev/fb0不可访问或者内核没开帧缓冲用root权限跑一遍排除权限问题。运行Qt程序时最容易被忽视的就是字体。Qt默认会去/usr/share/fonts、/usr/lib/fonts这样的标准路径找字体嵌入式文件系统里往往是空的。启动参数里用QT_QPA_FONTDIR指定你自己的字体目录或者干脆把字体文件放到系统标准目录都能解决。6.4 一个能帮你以后少走弯路的习惯把构建过程固化成脚本折腾完这一整套我最大的体会是这套编译流程不是一次性的很可能过三个月需求变了要重新编一次。到时候你是重新回忆还是看脚本我建议把整个configure和make步骤写成一个shell脚本放到Qt源码目录旁边。下次要重新构建跑一下脚本就能复现环境。更进一步如果用了Docker把整个工具链、sysroot、Qt编译环境打进镜像里以后换机器也是同一个命令拉起彻底告别环境差异问题。脚本里至少保留这几个关键信息#!/bin/bash export PATH/opt/Qt5.14.2-static-aarch64/bin:$PATH ./configure -prefix /opt/Qt5.14.2-static-aarch64 \ -opensource -confirm-license \ -release -static \ -platform linux-g \ -xplatform linux-aarch64-gnu-g \ -sysroot /usr/aarch64-linux-gnu \ -no-opengl -no-eglfs -no-dbus -no-icu -no-xcb \ -qt-zlib -qt-libpng -qt-libjpeg -qt-freetype -qt-harfbuzz \ -nomake examples -nomake tests make -j$(nproc) make install把环境变量、configure参数、make命令写清楚比任何文档都直观。6.5 关于LGPL合规的提醒Qt 5.14.2是LGPLv3/GPLv2双许可静态链接Qt库在商用分发场景下要注意LGPL条款要求如果你的程序动态链接Qt库那比较好办但静态链接意味着你把LGPL代码和你的代码打包在了一起就需要向接收方提供你程序的目标文件让接收方可以用它们替换静态链接的Qt库后重新链接。如果不想履行这个义务就得购买Qt商业授权。作为开发者这一步不搞清楚产品做大了可能惹上法律麻烦。虽然这属于许可问题不算技术问题但我觉得在静态Qt方案里必须提一句。写在最后一点实践心得整套Qt 5.14.2 aarch64静态交叉编译环境我从零搭完最想说的是不要怕configure那一大串参数每一个都是可解释的花一个小时把它们研究透后面能省一整天。我在实际项目里最后编译出来的界面程序大约28MB拷到板子上直接运行连环境变量都不用配这种感觉是真的舒服。另外如果手里暂时没有目标板强烈建议先在qemu里把程序跑通再发板这一步筛选掉的好多奇怪问题。等以后项目要支持触摸屏、要接GPU加速再回头改configure参数重新编译Qt整个流程你已经能完全掌控了。
