1. 从一块ARM64板子说起为什么一定要走QT6交叉编译1.1 板子到手之后的现实问题我手上这块ARM64 Debian开发板型号是orangepi CM5同类的国产小板四核A55跑Debian 12bookworm。系统装好、SSH连上、apt换完国内源之后第一件事想干什么无非是把QT6环境搭起来写个界面程序验证下显示效果。但等真正开始干的时候问题就来了直接在板子上编译QT6光是qtbase这一个模块全核跑满也要一个多小时。如果再算上qtdeclarative、qtquickcontrols2这些模块半天搭进去都算正常。板载编译听着简单可每改一次代码、每加一个依赖都要在板子上干等效率低到让人怀疑人生。交叉编译的思路说到底就一句话在性能强的x86_64机器上完成所有编译工作把生成好的二进制和依赖库部署到ARM64设备上运行。这样源代码编辑、编译、错误调试全在PC上完成板子只承担最后的运行环境。实测下来同样一个QT6项目PC上交叉编译大约只要板载编译的十分之一时间而且PC上可以开多线程、开ccache反复迭代的成本极低。1.2 为什么目标系统锁定了Debian选择Debian作为目标系统并不是因为我偏爱某个发行版而是因为工业级ARM开发板里Debian系是绝对的主流。从树莓派的Raspberry Pi OS到瑞芯微、全志、君正官方SDK里附带的系统几乎都基于Debian。这就带来一个巨大的优势arm64仓库里的二进制包可以直接解包进sysroot省去从源码编译底层库的大量时间。Debian的包管理机制对做交叉编译的人来说非常友好。需要哪个库的arm64版本直接在x86_64主机上apt-get download拿到.deb包后dpkg -x解压到sysroot目录头文件、静态库、动态库就全部到位了。我们后面会用这个办法装OpenGL、XCB、xkbcommon这些QT6的硬依赖比源码编译省事太多。1.3 QT6和QT5交叉编译的核心差异很多人之前玩过QT5的交叉编译网上教程也一堆但是QT6来了之后老经验有一半要作废。最大的变化是构建系统从qmake迁移到了CMake。QT6的configure脚本虽然还叫configure但底层已经是CMake的逻辑了很多QT5时代的参数不再生效编译产物里也不再自动生成那套lib/cmake/Qt6的CMake配置之外还会额外要求你用CMake toolchain file来接管交叉编译过程。另外QT6对C标准的要求更高17是底线部分模块已经开始用C20。这意味着交叉编译工具链必须够新Ubuntu 22.04自带的gcc-11、g-11可以Ubuntu 20.04的话最好手动升级到gcc-12以上。我刚开始就在这上面栽过跟头sysroot里的头文件和编译器版本不匹配报了一堆莫名其妙的模板错误。还有一个容易忽略的点QT6把QtWidgets和QtQuick都拆成了独立模块不再像QT5那样一个qtbase全装完。编译时要明确知道自己只需要哪个模块然后有选择地构建这样能大幅缩短编译时间。交叉编译时尤其如此因为你每多编一个模块就要多处理一份目标系统依赖。2. 环境准备工具链、arm64 rootfs、qemu三件套2.1 安装并验证交叉编译工具链在Ubuntu x86_64宿主机上安装aarch64工具链只需要两行命令sudo apt update sudo apt install -y gcc-aarch64-linux-gnu g-aarch64-linux-gnu装完确认一下版本aarch64-linux-gnu-gcc --version正常会输出gcc 11或12的版本信息。GCC交叉编译器默认就是一个“裸编译器”它只知道怎么生成arm64的机器码但并不知道目标系统的头文件和库在哪。所以下一步必须把target系统的rootfs准备好然后通过sysroot参数告诉编译器去哪里找。如果你用的是Ubuntu 22.04以下版本建议先检查一下libc6-dev-arm64-cross是否被自动安装了。这个包包含了arm64的C标准库头文件少了它编译任何程序都会报告找不到stdlib.h。2.2 用debootstrap构建最小化arm64 rootfssysroot是交叉编译的“地基”我习惯叫它sysroot本质上就是一套arm64 Debian的文件系统编译器在这个目录里找头文件和库。做法是用debootstrap拉一套最小的rootfs出来不做裁剪方便后续往里补包。sudo debootstrap --archarm64 bookworm /opt/arm64-sysroot https://mirrors.ustc.edu.cn/debian/为什么我推荐自己构建rootfs而不是直接下载官方根文件系统镜像因为debootstrap生成的目录是一个干净的起点你可以往里精确地安装依赖。而镜像根文件系统往往带了很多用不到的驱动和桌面组件体积大不说还可能跟宿主机产生冲突。自己构建的rootfs可以反复重建每次都是同一个干净状态容易用脚本固化。rootfs构建完之后往里面装QT6交叉编译需要的基础依赖。这里有个关键技巧使用chroot切换到arm64环境独立操作先安装qemu-user-static再chroot这样就能在rootfs内直接apt安装arm64的包。sudo cp /usr/bin/qemu-aarch64-static /opt/arm64-sysroot/usr/bin/ sudo chroot /opt/arm64-sysroot /bin/bash进入chroot后更新源并装依赖apt update apt install -y libgl1-mesa-dev libxkbcommon-dev libxcb-*-dev libfontconfig1-dev libfreetype6-dev libsqlite3-dev libicu-dev libpcre2-dev zlib1g-dev这里我特意装了libxcb-*-dev因为QT6的xcb平台插件运行时需要xcb相关的一系列库如果sysroot里缺这些库即使编译过了到板子上跑也会出现xcb插件加载失败。2.3 qemu-user-static是交叉编译的关键角色很多教程不会强调qemu但实际使用中我越来越察觉到它的重要。qemu-user-static在这里的作用是在x86_64宿主机上直接运行arm64的二进制程序。Qt6的configure阶段要执行大量小测试程序来检测目标系统特性比如检查某个头文件是否存在、某个函数能否链接这些测试程序是arm64架构的没有qemu就根本跑不起来。安装配置sudo apt install -y qemu-user-static binfmt-support sudo systemctl restart binfmt-support装完后测试一下qemu-aarch64-static /opt/arm64-sysroot/bin/ls一般还需要手动注册binfmt但Debian系的qemu-user-static安装默认会自动注册。如果发现aarch64程序执行报Exec format error检查/proc/sys/fs/binfmt_misc/目录是否有对应的注册项ls /proc/sys/fs/binfmt_misc/里面应该有qemu-aarch64条目状态是enabled。整个环境凑齐后我用一个hello world来验证sysroot整体可用性cat /tmp/hello.cpp EOF #include iostream int main() { std::cout hello arm64 std::endl; return 0; } EOF aarch64-linux-gnu-g --sysroot/opt/arm64-sysroot /tmp/hello.cpp -o /tmp/hello qemu-aarch64 /tmp/hello如果看到“hello arm64”输出说明工具链、sysroot、qemu都正常协同工作了。别看这只是个小程序它能一次性排除工具链问题、sysroot路径问题、qemu配置问题三大类隐患。2.4 sysroot里最容易缺的依赖清单我踩坑早期最常见的错误就是编译到一半报某个头文件找不到然后才意识到sysroot里没装对应的-dev包。交叉编译对目标系统的完整性要求很高建议直接用一份清单管理起来不同板子、不同项目都能复用。模块用途需要的包备注OpenGL/EGLlibgl1-mesa-dev, libegl1-mesa-devQT6默认需要OpenGLxcb平台libxcb-*-dev多个子包生成xcb插件的前置字体libfontconfig1-dev, libfreetype6-dev文字渲染ICUlibicu-dev国际化、Unicode支持网络libssl-devQtNetwork的TLS支持如果你做的是嵌入式开发板、无桌面环境可以用-platform linuxfb的offscreen方式运行但那需要目标系统里有对应的framebuffer驱动不推荐全场景使用。最通用的还是装全xcb依赖以窗口模式运行。3. QT6源码与CMake工具链文件configure的核心参数拆解3.1 下载并理解QT6源码的目录结构我使用的是qt-everywhere-src的发布包下载好解压后你会发现它的目录组织方式和QT5有本质区别。以6.2/LTS版本为例解压后是一个包含qtbase、qtdeclarative、qtmultimedia、qttools等子目录的聚合仓库每个子目录本质上都是一个独立的CMake工程。qtbase是地基其他模块依赖它。交叉编译的时候不需要编译所有模块一是没那么多时间二是目标设备空间有限。用-skip参数把用不到的模块都跳掉我通常只保留qtbase、qtdeclarative、qtquickcontrols2、qtsvg这四个IoT类界面已经完全够用。3.2 交叉编译toolchain文件一改一个准qtbase本身的configure可以串联交叉编译但你的应用程序要用CMake构建所以一个通用的交叉编译toolchain文件是必须的。我习惯把它放在工程目录之外作为一个系统级配置文件比如/opt/arm64-toolchain.cmake。内容如下set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR aarch64) set(CROSS_COMPILE aarch64-linux-gnu-) set(SYSROOT /opt/arm64-sysroot) set(CMAKE_SYSROOT ${SYSROOT}) set(CMAKE_C_COMPILER ${CROSS_COMPILE}gcc) set(CMAKE_CXX_COMPILER ${CROSS_COMPILE}g) set(CMAKE_FIND_ROOT_PATH ${SYSROOT} /opt/qt6-arm64) 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_FIND_ROOT_PATH_MODE_PROGRAM NEVER是必须的因为CMake在查找程序比如可执行工具时应该找宿主机的程序而不是目标系统的程序。如果你设成ONLYCMake会去sysroot里找host工具大概率找不到或者找错。第二CMAKE_FIND_ROOT_PATH里我加了两个路径一个是sysroot另一个是后面要安装的QT6目标目录。这样CMake除了在sysroot里找系统库还能找到QT6编译好后的CMake配置文件。第三CMAKE_SYSROOT和CMAKE_FIND_ROOT_PATH是两个不同的概念。前者告诉编译器“头文件和库相对于这个路径找”后者告诉CMake“查找库和包的时候额外搜索这个路径”。两者可以同时设置但不要互相替代。3.3 configure时的三板斧-sysroot、-extprefix、-deviceQT6的configure脚本是一个Python脚本底层调用CMake。交叉编译的关键参数如下cd /path/to/qt-everywhere-src-6.5.3 ./configure \ -device linux-aarch64-gnu-g \ -device-option CROSS_COMPILEaarch64-linux-gnu- \ -sysroot /opt/arm64-sysroot \ -prefix /usr/local/qt6 \ -extprefix /opt/qt6-arm64 \ -opensource -confirm-license \ -release \ -nomake examples -nomake tests \ -skip qttools -skip qttranslations -skip qtwebengine \ -skip qtsensors -skip qtwayland -skip qtconnectivity参数逐个说-device linux-aarch64-gnu-g指定目标设备平台。QT6提供了一套预定义的mkspec路径在qtbase/mkspecs/devices/linux-aarch64-gnu-g。这个mkspec里定义了目标系统的一些默认编译选项、链接选项和小特性测试。-device-option CROSS_COMPILEaarch64-linux-gnu-告诉编译器前缀qmake和构建脚本都会用这个前缀拼接出交叉编译器的完整命令。-sysroot /opt/arm64-sysroot指定目标系统根目录configure会从这里找依赖库。-prefix /usr/local/qt6这是目标系统上的安装路径千万不能写成宿主机的路径。因为你安装的时候是装到-extprefix指定的宿主机目录但运行时库文件按-prefix的路径嵌入。-extprefix /opt/qt6-arm64指定实际安装目录交叉编译时这个目录在宿主机上最后整体部署到设备上时再按-prefix的路径摆放。configure成功后用cmake --build . --target install或老的make -j$(nproc)构建并安装。这里要等一阵子qtbase全量构建在8核PC上大约10到15分钟。构建完成后/opt/qt6-arm64下会有完整的lib、include、plugins、lib/cmake等目录。3.4 让pkg-config在交叉编译时“指哪打哪”QT6自身用CMake的package查找机制不再依赖pkg-config来找qt模块但我们在编译第三方库或者自己的工程时仍然会用到pkg-config。交叉编译时如果不做特殊处理pkg-config默认会去找宿主机的.pc文件导致链接错库。解决办法是在环境变量里把所有pkg-config相关路径都指向sysrootexport PKG_CONFIG_DIR export PKG_CONFIG_LIBDIR/opt/arm64-sysroot/usr/lib/aarch64-linux-gnu/pkgconfig:/opt/arm64-sysroot/usr/lib/pkgconfig:/opt/arm64-sysroot/usr/share/pkgconfig export PKG_CONFIG_SYSROOT_DIR/opt/arm64-sysrootPKG_CONFIG_SYSROOT_DIR尤其关键它会把.pc文件里的前缀自动加上sysroot路径。比如某个.pc文件写了prefix/usr实际查找头文件就会变成/opt/arm64-sysroot/usr/include。不设置这个变量pkg-config输出的编译参数全部指向宿主机路径交叉编译器根本找不到arm64的头文件。4. 跑通一个最小QT6程序从编译到设备运行的全链路4.1 写一个带界面的最小工程环境都就绪之后就该建一个真正的QT6程序来验证。先用基础的QApplication QLabel写一个hello world工程有了这个底子再慢慢加widgets、布局、信号槽。main.cpp#include QApplication #include QLabel int main(int argc, char *argv[]) { QApplication app(argc, argv); QLabel label(QT6 Cross Compile OK on arm64 dev board); label.resize(480, 240); label.show(); return app.exec(); }CMakeLists.txtcmake_minimum_required(VERSION 3.21) project(qt6_demo LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) find_package(Qt6 REQUIRED COMPONENTS Widgets) qt_standard_project_setup() qt_add_executable(qt6_demo main.cpp) target_link_libraries(qt6_demo PRIVATE Qt6::Widgets)注意这里用了qt_standard_project_setup()这是QT6.3以后推荐的新写法会自动设置CMAKE_AUTOMOC等属性。如果你用的是6.2之前的老版本需要手动设置set(CMAKE_AUTOMOC ON)。4.2 交叉编译构建把toolchain文件路径传给CMakemkdir build-arm64 cd build-arm64 cmake .. \ -DCMAKE_TOOLCHAIN_FILE/opt/arm64-toolchain.cmake \ -DCMAKE_PREFIX_PATH/opt/qt6-arm64 \ -DCMAKE_BUILD_TYPERelease make -j$(nproc)构建完成后在build-arm64目录下会有qt6_demo可执行文件。你可以用file命令确认它是ARM64架构file qt6_demo输出qt6_demo: ELF 64-bit LSB executable, ARM aarch64, dynamically linked, ...到这一步交叉编译的主流程就跑通了。但这只是“能编”离“能跑”还有一段路。4.3 部署到板子不是拷一个二进制就完事很多人第一次交叉编译在设备上运行报错就是因为只拷贝了编译好的可执行文件。但QT6程序是动态链接的在宿主机上编译时链接的是sysroot里的arm64库运行时要到设备上找对应的arm64库。如果设备上没有装QT6程序一启动就会报error while loading shared libraries: libQt6Widgets.so.6: cannot open shared object file一种办法是把整个/opt/qt6-arm64目录拷贝到板子上去。我通常用rsync保持目录结构和权限rsync -avz /opt/qt6-arm64/ root板子IP:/opt/qt6-arm64/然后设置运行环境export LD_LIBRARY_PATH/opt/qt6-arm64/lib:$LD_LIBRARY_PATH export QT_QPA_PLATFORM_PLUGIN_PATH/opt/qt6-arm64/plugins/platforms export QT_QPA_PLATFORMxcb如果你的板子没有显示器而是通过SSH可以用QT_QPA_PLATFORMoffscreen先测试不依赖显示的程序逻辑。带界面的话要么接HDMI显示器要么用x11转播。拷贝时有个小技巧只拷贝lib目录、plugins目录、qml目录不要拷贝include、cmake这些开发文件。运行时只需要动态库和插件开发文件拷贝过去纯属浪费空间。4.4 用qemu先在本机验证运行逻辑如果没有板子在手边也可以先在宿主机上验证程序能否正确加载QT6库qemu-aarch64 -L /opt/arm64-sysroot -E LD_LIBRARY_PATH/opt/qt6-arm64/lib ./qt6_demo-L指定模拟运行时的动态库搜索路径-E传递环境变量。如果你的程序用到了xcb这个命令会因为缺少X server而失败但如果是offscreen模式qemu-aarch64 -L /opt/arm64-sysroot \ -E QT_QPA_PLATFORMoffscreen \ -E LD_LIBRARY_PATH/opt/qt6-arm64/lib \ ./qt6_demo程序能够正常启动并进入事件循环说明QT6运行环境的库依赖是完整的。这个小技巧帮我排查过好几次问题不需要反复往板子上拷贝文件。5. 疑难问题排查链路四个深坑的完整复盘5.1 configure时编译测试程序失败找不到stdlib.h现象执行./configure到大约40%进度时CMake测试编译一个最简单的C程序报一堆fatal error核心是stdlib.h: No such file or directory。排查链路我一开始以为是sysroot没配好反复检查路径都没问题。后来单独写了hello.cpp用aarch64-linux-gnu-g手动编译同样报找不到stdlib.h。这时候才意识到不是sysroot的锅而是交叉编译器本身找不到libc6-dev-arm64-cross的sysroot路径。用一条命令定位aarch64-linux-gnu-g -v -E -x c /dev/null会输出编译器的内部默认搜索路径如果那里没有指向/usr/aarch64-linux-gnu或自定义sysroot就说明编译器在裸状态下确实找不到目标系统的C标准库头文件。修复检查发现我是用sudo apt install gcc-aarch64-linux-gnu单独装的编译器但没有自动装上libc6-dev-arm64-cross。补装之后编译器默认能在/usr/aarch64-linux-gnu/include找到标准头文件了。然后configure命令里的-sysroot才真正起作用因为编译器知道除了默认路径之外再去sysroot里找。经验交叉编译报头文件缺失先查编译器自带的sysroot搜索路径再查自己配置的sysroot。很多情况是g -v输出里压根没有目标系统头文件路径。5.2 编译QT6时出现undefined reference to EGLContext现象qtbase编译到某个环节链接egl相关的库时大量报undefined reference to eglGetCurrentContext之类。排查链路QT6对OpenGL的支持有两个层面一个是运行时通过动态加载OpenGL库另一个是编译时必须找到OpenGL的头文件。在交叉编译时QT6会检测EGL和GLES相关库是否存在。sysroot里虽然装了libgl1-mesa-dev但没有装libegl1-mesa-dev导致cmake检测到的EGL头文件存在但库缺失。修复sudo chroot /opt/arm64-sysroot /usr/bin/apt install -y libegl1-mesa-dev libgles2-mesa-dev重新跑configure这次EGL检测通过链接正常。经验Qt6默认启用OpenGL相关功能如果目标设备是嵌入式板卡GPU驱动没接好还会有更多GL相关的坑。可以试试用-no-opengl直接禁用OpenGL或者-platform linuxfb用纯软件渲染。但GUI显示效果会打折扣尽量还是接好GL管线。5.3 板子上运行报找不到xcb平台插件现象程序在板子上启动立刻退出qt.qpa.plugin: Could not find the Qt platform plugin xcb in 排查链路这个报错分两种情况。一是QT_QPA_PLATFORM_PLUGIN_PATH没设置或者设错了路径插件实际上没加载到。二是sysroot里缺xcb相关库导致xcb插件根本没编译出来。先检查第二种看/opt/qt6-arm64/plugins/platforms/下有没有libqxcb.so。没有的话说明configure时就漏配了依赖。有的话就用ldd检查这个插件缺哪些依赖aarch64-linux-gnu-readelf -d /opt/qt6-arm64/plugins/platforms/libqxcb.so | grep NEEDED然后对照板子上的/usr/lib/aarch64-linux-gnu目录看缺哪个库。修复我遇到的情况是libqxcb.so存在但板子上缺少libxcb-cursor0这个库在Debian 11及以下可能没有。装上它问题解决。QT6.4以上版本对libxcb-cursor有硬性依赖这是新版本特有的坑我在网上看到一个典型报错Failed to load xcb-cursor0 or libxcb-cursor.so.0确实是这个原因。还有一个小细节如果你是root用户跑QT程序有时xcb加载成功但连不上X server因为X server默认不接受root连接加了-nolisten tcp等参数后才好。测试时建议直接用普通用户运行减少权限干扰。5.4 我编译的QT6项目依赖OpenCV时opencv找不到现象自己写的工程里用了OpenCV按常规在tree查找find_package(OpenCV)死活找不到明明sysroot里已经通过apt装了libopencv-dev:arm64。排查链路问题出在CMake的find_package(OpenCV)查找的是OpenCV自己的CMake配置文件OpenCVConfig.cmake而这个文件放在/usr/lib/aarch64-linux-gnu/cmake/opencv4/。CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY让CMake在sysroot里搜索但它找的路径是sysroot下常见的lib/cmake而不一定会自动去找lib/aarch64-linux-gnu/cmake这种多架构路径。修复在toolchain文件里增加对CMAKE_LIBRARY_ARCHITECTURE的说明set(CMAKE_LIBRARY_ARCHITECTURE aarch64-linux-gnu)这样CMake在sysroot里查找时会把lib/aarch64-linux-gnu也纳入搜索范围。重新cmakeOpenCV找到了。经验Debian系的多架构目录结构是交叉编译的一个隐藏陷阱。不只是OpenCV像FFmpeg、Boost、sqlite这些库的CMake配置全部放在lib/aarch64-linux-gnu/cmake里不设置CMAKE_LIBRARY_ARCHITECTURE就会遇到这种“包就装了但找不到”的怪象。6. 工程化进阶让交叉编译环境可持续复用6.1 把sysroot当工程资产来管理交叉编译环境不用每次从零搭建。我个人的做法是把debootstrap、chroot里装包的命令、qemu配置全部写成脚本放到git仓库里。这样新同事拿到项目代码跑一条./setup_sysroot.sh就能把完整环境拉起来。sysroot本身也可以打包归档。tar -czf arm64-sysroot.tar.gz /opt/arm64-sysroot解压后路径保持一致即可。只要是同一套sysroot编译出来的二进制就会保持稳定。频繁重装sysroot是大忌因为不同时间apt仓库的包版本会有差异哪怕只差一个小版本也可能导致编译出的程序行为不一致、甚至根本跑不了。6.2 用Ninja替代Make来加速QT6构建QT6默认的构建系统在Linux上是Unix Makefiles但我实测用Ninja生成器在并行构建时效率更高。Configure后的构建命令可以这样cmake --build . --parallel 16 --target install如果configure时没指定Generator也可以后续单独配置cmake -G Ninja . ninja install用Ninja之后增量编译的速度有明显提升。QT6这种大项目每次改一个模块的头文件Makefile可能级联触发大量重编而Ninja的执行策略要精细得多。6.3 写一个CMakePresets.json方便团队协作CMakePresets.json是CMake 3.21提供的新机制可以把工具链、构建目录、缓存变量固化到一个文件里。我建议你的工程根目录放一份这样的配置{ version: 3, configurePresets: [ { name: arm64-release, displayName: ARM64 Debian Release, generator: Ninja, binaryDir: ${sourceDir}/build-arm64, cacheVariables: { CMAKE_TOOLCHAIN_FILE: /opt/arm64-toolchain.cmake, CMAKE_PREFIX_PATH: /opt/qt6-arm64, CMAKE_BUILD_TYPE: Release, CMAKE_LIBRARY_ARCHITECTURE: aarch64-linux-gnu } } ], buildPresets: [ { name: arm64-release, configurePreset: arm64-release } ] }之后团队成员只需cmake --preset arm64-release cmake --build --preset arm64-release再也不用把人肉那个又长又容易敲错的CMake命令复制来复制去。一开始配置好这一层后面能省不少沟通成本和环境不一致导致的无谓问题。6.4 我踩过无数次坑后总结出的三条铁律第一条工具链版本和sysroot必须配对。用gcc-12就最好从Debian bookworm的仓库构建rootfs不要用Ubuntu 22.04的gcc-11去编译Debian bookworm的库虽然大部分情况下能跑但在C20相关的模板实例化、std::filesystem这类相对较新的特性上很容易出玄学错误。第二条全程用环境变量把交叉编译上下文固定下来。我在.bashrc里固定设置export QT_CROSS_SYSROOT/opt/arm64-sysroot export QT_CROSS_PREFIX/opt/qt6-arm64 export PATH/opt/qt6-arm64/bin:$PATH export PKG_CONFIG_LIBDIR$QT_CROSS_SYSROOT/usr/lib/aarch64-linux-gnu/pkgconfig:$QT_CROSS_SYSROOT/usr/lib/pkgconfig export PKG_CONFIG_SYSROOT_DIR$QT_CROSS_SYSROOT新开一个终端只要source一下所有编译命令都默认指向交叉编译环境不会再出现“用宿主机的pkg-config返回了x86_64的库路径”这种问题。第三条在板子上跑之前先在qemusysroot环境里用offscreen模式跑一遍。这能在不用实际硬件的情况下暴露90%的库缺失问题。特别是当一个板子有多台、硬件还没到货的阶段这一招能让你提前把应用逻辑调完板子一到直接部署运行效率极高。回到文章开头的问题有了这套交叉编译流程我手里这块arm64板子从最开始“装个QT6要半天”到现在从拿到源码到部署运行新功能二十分钟全部搞定。QT6交叉编译真正上手之后会发现它没有想象中那么神秘本质上就是一套标准的交叉工具链加一个CMake的sysroot导向逻辑但要把各种边界情况都理顺确实需要一场一场的实坑来补课。希望我这几个踩坑复盘能帮你少走点弯路。
