★ FEATURED ARTICLE 写这篇东西的起因是上个月帮团队在一批 ARM 架构的国产笔记本上部署 Qt 开发环境。机器预装的是统信 UOS系统里确实自带 Qt 库但版本偏旧而且缺一堆开发组件。网上关于“ARM UOS Qt 源码编译”的资料零零散散翻遍论坛也没找到一篇能从头跟到尾的实战记录。折腾了差不多一个周末总算把 Qt 5.15.2 从源码编出来顺带还把 Qt Creator 也定制了一版。这篇文章就把整个流程、踩过的坑、以及为什么要这么干的底层逻辑全部理清楚给同样被 ARM 环境折磨的朋友一条能直接照抄的路。先说这篇文章适合谁手里有 ARM 架构机器飞腾、鲲鹏、麒麟、苹果 M 系列装虚拟机跑 UOS 也算、需要在 UOS 上做 Qt 应用开发、觉得 apt 提供的 Qt 不够用、或者想自己魔改 Qt Creator 的开发者。文章非常长核心思路是先把“为什么”讲透再按步骤给你能执行的命令最后附上我实际遇到的排查案例。1. 为什么非要源码编译UOS 里自带 Qt 的尴尬现状1.1 你拿到的 UOSQt 到底缺了什么统信 UOS 基于 Debian 系构建使用 apt 包管理理论上一条sudo apt install qt5-default就能装好 Qt。但实际开发中你会发现这种方式装的 Qt 有几个非常难受的问题。首先版本滞后。UOS 的软件源里 Qt 版本通常停留在 5.11 或 5.13而 Qt 5.15.2 是 LTS长期支持版本修复了大量性能漏洞和已知崩溃问题尤其是对高分辨率屏幕的适配和 Wayland 协议的完善程度这两个版本差距很大。在 2K 甚至 4K 屏的国产笔记本上旧版 Qt 界面会出现明显的模糊和缩放错乱没调整好的话整个应用看起来像蒙了一层纱。其次组件缺失。apt install qt5-default只装了基础模块Qt WebEngine、Qt Charts、Qt Data Visualization这些组件根本不会带。等你要集成一个浏览器内核或者画个饼图才发现还得费劲找对应的 dev 包运气不好直接依赖冲突。第三不是针对目标架构优化过的。这句话要分两层理解如果 UOS 本身运行在 ARM 上apt 源里提供的是 ARM64 版本的二进制包基础运行没问题但性能参数是通用的不会针对你的特定 CPU 做指令集优化如果你要在 ARM 设备上做交叉编译让程序跑在另一个架构上那 apt 装的开发库根本不支持交叉编译场景。1.2 源码编译到底带来了什么源码编译的本质是“一切从最底层开始重新构建”。对于 Qt 这样体量的框架源码编译意味着你可以自己指定编译参数、裁剪组件、决定安装目录甚至在动手前修改部分源码。举个最实在的例子嵌入式项目的目标设备可能没有 GPU没有 OpenGL 加速你就需要编译一个使用软件渲染-qt-libpng、-xcb -qt-xcb的 Qt 版本去掉不需要的模块以减少体积。这种极致裁剪二进制包永远做不到。再一个调试体验完全不同。从源码编译 Qt 库gdb 调试时可以带-debug或-release参数把调试符号保留下来崩溃时能直接看到 Qt 内部的调用栈定位问题效率高得多。最典型的是定位原生崩溃问题比如 QML 渲染异常导致的段错误有了符号表一查一个准。1.3 但源码编译也有明显的代价诚实地说源码编译不是银弹在 ARM 设备上更是如此。最大的代价是时间。以一台 8 核的飞腾 D2000 处理器为例编译 Qt 5.15.2 的常规配置大约需要 60 到 90 分钟如果加上 WebEngine 模块一晚上都未必跑完。我之前在同一台机器上用-nomake examples -nomake tests精简配置连续编了差不多两个小时。其次是依赖地狱。Qt 的依赖涉及图形栈libxcb、libxkbcommon、libGL、字体栈fontconfig、freetype、网络加密openssl、libicu任何一个库版本不对configure 阶段直接报错退出。环境准备不充分就是反复地在“装依赖—配置—报错—再装依赖”之间循环。所以动手前的判断非常重要如果你的项目只是简单工具类应用系统 Qt 完全够用那真不推荐折腾源码编译。但如果要做产品级应用、需要跨平台部署、还要深度定制特性那这一步是绕不过去的坎。2. 动手前必须搞定的环境准备少踩一个坑是一个2.1 确认你的具体架构与系统版本在 UOS 上打开终端执行下面的命令uname -m cat /etc/os-releaseuname -m会输出处理器架构ARM 设备通常显示aarch64也有部分早期设备显示armv7l。/etc/os-release能看到系统版本比如 UOS 20 或 UOS 1060。这里有个容易踩的误区看到aarch64就以为是 64 位 ARM直接下载 ARM64 的源码包开始编译。但实际上飞腾和华鲲的一些设备虽然指令集兼容 ARMv8厂商可能修改了引导和固件某些系统库是定制的。保险起见编译前先确认一下软件源是否可用sudo apt update如果更新源都失败先解决软件源的问题再往下走。UOS 的 apt 源偶尔会因为内网环境失效常见做法是检查/etc/apt/sources.list和/etc/apt/sources.list.d/下的文件确认指向的地址是官方源还是内网镜像。2.2 安装编译工具链gcc、g、make 和基础库UOS 默认不一定装了完整的编译工具链先用一行命令装上sudo apt install -y build-essential这会安装 gcc、g、make 等基础工具。然后安装 Qt 编译所需的额外依赖sudo apt install -y libxcb* libxkbcommon-dev libxkbcommon-x11-dev libgl1-mesa-dev libfontconfig1-dev libfreetype6-dev libssl-dev libicu-dev libdbus-1-dev libegl1-mesa-dev libgles2-mesa-dev这里解释一下为什么需要这些库。libxcb*X11 通信协议的核心库。Qt 的 xcb 平台插件就是基于它实现的没有它编译出来的 Qt 无法在 X11 桌面上显示任何窗口。UOS 默认走的是 X11 协议虽然也有 Wayland 支持但 xcb 是老牌稳定路线。libxkbcommon-dev键盘映射和输入法支持没有它键盘事件会乱套。libgl1-mesa-dev、libegl1-mesa-devOpenGL 和 EGL 的开发库。对硬件加速渲染至关重要尤其是需要 OpenGL 窗口的场景。libfontconfig1-dev、libfreetype6-dev字体渲染。Qt 字体发虚、字体缺失的问题一半以上和这两个库有关。libssl-dev、libicu-dev网络模块和国际化所用。Qt WebEngine、QML 的某些模块都会依赖它们。提示不要在 ARM 设备上试图用apt install qt5-default来解决 Qt 库依赖问题这会污染系统版本后续源码编译安装会造成版本冲突。保持系统自带 Qt 不变源码编译的 Qt 单独放一个目录。2.3 讨论一下 Qt 5.15.2 版本选择的合理性很多人会问为什么不装 Qt 6都已经 2026 年了。这个问题在企业项目里很现实。Qt 6 从架构上做了大量调整尤其是渲染抽象层RHI对 OpenGL 的依赖路径、窗口系统集成方式都和 Qt 5 不同。但对于很多国产化项目基于 Qt 5.15 LTS 的稳定生态仍然是主流。商用项目涉及大量存量代码直接升 Qt 6 的迁移成本极高。另外操作系统厂商包括 UOS 和麒麟官方适配的工具链目前依然以 Qt 5.15 为中心大多预装的 Qt 5.15 库作为系统基础。选择 Qt 5.15.2 意味着最大化兼容现有国产操作系统平台这也是为什么我们最终定在版本 5.15.2 而不是更高的 5.15.x。注意5.15.2 是 LTS 版本的第一个补丁版本网上有些破解版安装包有安全风险建议直接到 Qt 官网或镜像站下载源码。3. Qt 5.15.2 源码编译完整实操一条命令都不能错3.1 下载源码包与校验打开 Qt 官方下载地址或者使用清华镜像源找到qt-everywhere-opensource-src-5.15.2.tar.xz。注意看文件名里的everywhere这是 Qt 官方把所有模块打包在一起的发行版。如果只要核心模块也可以单独下载qtbase但后续 Qt Creator 编译会缺少大量模块建议还是用完整包。下载后核对 SHA-1 校验值官方md5sum列表里能查到避免下载了损坏的文件白折腾。具体校验命令md5sum qt-everywhere-opensource-src-5.15.2.tar.xz解压到工作目录我习惯放在/opt下面方便统一管理sudo mkdir -p /opt/qt-build sudo tar -xJf qt-everywhere-opensource-src-5.15.2.tar.xz -C /opt/qt-build3.2 configure 阶段这是决定成败的地方进入源码目录执行配置。网上各种教程里这段差异非常大给出来的参数也不一样。我参考多台 ARM 设备实测可行的一套参数如下cd /opt/qt-build/qt-everywhere-opensource-src-5.15.2 ./configure \ -prefix /opt/Qt/5.15.2/gcc_64 \ -opensource \ -confirm-license \ -release \ -optimized-qmake \ -xcb \ -bundled-xcb-xinput \ -qt-xcb \ -no-opengl \ -nomake examples \ -nomake tests \ -skip qtwebengine \ -skip qtwayland \ -skip qtscript \ -skip qtconnectivity \ -skip qtsensors \ -skip qtserialbus \ -skip qtgamepad \ -skip qtspeech逐个解释这些参数因为每一个都是基于实践踩过坑后总结的-prefix指定 Qt 安装目录。/opt/Qt/5.15.2/gcc_64是 Qt 官方默认的 Linux 安装前缀结构后续 Qt Creator 能自动识别这个路径。注意如果后续要用 Qt Creator 里的 Kit 自动检测这个路径越接近官方默认越好。-opensource -confirm-license: 选择开源版本自动确认 LGPL 协议。如果不加configure 中途会交互式询问在纯命令行环境或者 CI 环境会卡住。-release: 编译发行版会做优化。如果想调试 Qt 源码加-debug-and-release可以编译双版本但体积和时间都会翻倍。我们这边为了开发效率选了 release。-xcb -qt-xcb -bundled-xcb-xinput: 在 ARM UOS 上太关键了。-qt-xcb表示使用 Qt 自带的 xcb 库不依赖系统版本-bundled-xcb-xinput是让 xcb 带上 xinput 支持否则触摸屏、手写笔输入会有延迟或者无法正确识别。国产设备很多带触摸屏这个参数能省掉后续很多适配问题。-no-opengl: 这个参数是有争议的。ARM 设备上 OpenGL 驱动质量参差不齐某些设备上 Mesa 驱动不稳定反而导致 Qt 启动时崩溃。对绝大多数企业级 UI 应用控件、报表、业务流程界面来说软件渲染完全够用且稳定得多。做了这个选择后Qt 内部会自动走 raster 即软件渲染画面流畅度没问题但不适合做复杂的三维渲染比如高精度地图 3D 模式。-nomake examples -nomake tests: 不编译官方示例和测试程序能节省大量时间和磁盘空间实际开发中没人会去看示例等真的需要示例时直接浏览官方在线文档即可。-skip qtwebengine: 跳过 Web 内核模块。这是整个 Qt 编译中耗时最长、最容易出问题的模块它底下是 Chromium就算只编译一次也要占 20 多 GB 的临时空间在 ARM 上编译时还会因为链接器内存不足频繁失败。如果你的应用不需要内嵌网页浏览器这个模块跳过是最理智的选择。-skip qtwayland: UOS 上 X11 和环境集成非常稳定Wayland 相关模块可以先不编译。其他-skip项目都是低频使用的模块跳过能减少编译时间。如果你项目里有针对蓝牙QtConnectivity或传感器QtSensors的需求记得保留对应模块。执行完 configure 后注意看终端输出的最后一段是否有 ERROR。如果提示缺少依赖库继续安装对应包重新执行 configure。configure 脚本本身具备增量逻辑重跑不会出问题。3.3 make 编译耐心与机器性能的博弈configure 通过后开始编译。ARM 设备编译耗时很长建议设置环境变量避免内存不足export MAKEFLAGS-j4 make-j4表示 4 个并行编译任务这里根据 CPU 核心数调整。很多人习惯-j$(nproc)但在内存不足的嵌入式设备上过高的并行度会导致内存耗尽直接编译崩溃。8 核设备的经验值是-j4或-j6比-j8更加稳妥。编译过程中可以用htop实时查看内存占用如果 Swap 使用率持续高位果断 CtrlC 后降并行数重来。等待期间别闲着建议执行一个反向依赖检查apt-cache rdepends libc6 | head确认系统关键库不会被后续操作损坏。虽然这一步对 Qt 编译本身无用但能帮你建立环境变化的全局观防止改乱了系统库路径。编译结束后开始安装到指定目录sudo make install注意make install需要 root 权限它会创建你在-prefix指定的目录并拷贝文件。安装完成后添加环境变量。编辑/etc/profile.d/qt515.sh文件sudo tee /etc/profile.d/qt515.sh EOF export PATH/opt/Qt/5.15.2/gcc_64/bin:$PATH export LD_LIBRARY_PATH/opt/Qt/5.15.2/gcc_64/lib:$LD_LIBRARY_PATH export QT_PLUGIN_PATH/opt/Qt/5.15.2/gcc_64/plugins export CMAKE_PREFIX_PATH/opt/Qt/5.15.2/gcc_64 export QT_QPA_PLATFORM_PLUGIN_PATH/opt/Qt/5.15.2/gcc_64/plugins/platforms EOF然后执行source /etc/profile.d/qt515.sh验证安装qmake -v如果输出 QMake version 是 3.1Qt version 是 5.15.2说明核心编译已经成功。3.4 一个非常容易忽略的问题Qt 的字体与中文环境UOS 上源码编译的 Qt 坑爹的地方之一是默认字体会和系统字体应用脱节。代码里如果直接指定Microsoft YaHei这种字体名在 UOS 上会找不到直接回退到默认字体导致界面出现方块字。解决办法是先查看系统有哪些中文字体fc-list :langzhUOS 默认带 Noto Sans CJK SC 或文泉驿字体。代码里统一使用Noto Sans CJK SC或者干脆让 Qt 自动选择字体不手动指定。这个问题在编译后的 Qt 应用中极其常见属于环境适配的隐藏坑。4. 定制 Qt Creator从源码构建符合自己习惯的 IDE4.1 先搞清楚 Qt Creator 在整个流程中的位置Qt Creator 是一个集成开发环境它本身是基于 Qt 开发的也就是说刚才编译出来的 Qt 库就是运行 Qt Creator 的前提。为什么要自己编译 Qt Creator而不是直接下载现成的安装包原因有几层一是直接下载安装包可能要带图形界面交互ARM 环境下部分组件不太好用版本兼容性易出问题二是官方安装包是通用版本插件体系固定。对于需要深度集成的内部工具链比如定制化的代码格式化插件、私有构建系统必须从源码编译并加载自己的插件三是版本对齐。官方二进制版本可能和你的 Qt 版本有细微 API 差异影响编译兼容性。从源码编译就能保证和 Qt 库完全同频。4.2 Qt Creator 源码获取与依赖准备从 Qt 官方仓库获取源码在 UOS 上先安装需要的构建工具sudo apt install -y cmake ninja-build clang lld python3 perlQt Creator 的新版本采用 CMake 构建系统同时需要 Python 和 Perl 处理一些自动化脚本。然后克隆源码git clone https://code.qt.io/cgit/qt-creator/qt-creator.git -b 4.15.2注意这里版本的选择4.15.2 是和 Qt 5.15.2 配套的稳定分支。如果你用更高版本的 Qt Creator构建时可能会要求 Qt 5.15 以上的 API但兼容性需要打补丁很麻烦。选择这条分支可以与 Qt 5.15.2 完全契合。4.3 定制修改的思路从需求出发不做无用功“定制 Qt Creator”这个说法听上去很玄实际上你完全可以按自己的需求来改。我这里提供一个最简单的定制实例作为参考思路在 Qt Creator 的帮助菜单里增加一个“公司文档”入口点击后直接打开内部 Wiki 页面。修改源码位置是src/plugins/help/helpplugin.cpp找到HelpPlugin::initialize()函数在初始化逻辑中加入自定义菜单项#include coreplugin/actionmanager/actionmanager.h #include coreplugin/id.h #include QDesktopServices #include QUrl #include QMenu #include QAction void HelpPlugin::addCompanyDocAction() { Core::ActionManager *am Core::ActionManager::instance(); Core::Context globalContext(Core::Constants::C_GLOBAL); QAction *companyDocAction new QAction(tr(公司技术文档), this); connect(companyDocAction, QAction::triggered, this, []() { QDesktopServices::openUrl(QUrl(https://wiki.internal.company.com)); }); Core::Command *cmd am-registerAction(companyDocAction, Company.Doc, globalContext); cmd-setDefaultKeySequence(QKeySequence(Qt::CTRL | Qt::SHIFT | Qt::Key_D)); QMenu *helpMenu nullptr; // 通过 QMenuBar 遍历找到 Help 菜单 // 实际代码需要结合版本 API 做适配 if (helpMenu) helpMenu-addAction(cmd-action()); }插件的核心逻辑是利用 Qt Creator 自身的 ActionManager 注册新的动作设置快捷键然后把对应的 QAction 挂载到主菜单栏上。这种定制对 IDE 的核心代码零侵入纯做加法。当然这只是举例通常真正企业化定制还会做这些事内置自定义构建步骤比如一键打包 deb 包调整默认代码模板统一团队代码风格增加构建套件Kit自动探测逻辑把交叉编译工具链和 Qt 库自动关联。这些定制点分散在各插件模块如果你之前没碰过 Qt Creator 源码想快速上手可以在源码目录搜索addAction、registerAction等关键词看官方插件是怎么写的照葫芦画瓢改。4.4 编译安装 Qt Creator在源码根目录建立构建目录mkdir build cd build cmake .. -DCMAKE_PREFIX_PATH/opt/Qt/5.15.2/gcc_64 -DCMAKE_BUILD_TYPERelease make -j4 sudo make installCMAKE_PREFIX_PATH指定刚才编译的 Qt 所在路径这个参数确保了 CMake 能够找到对应版本的 Qt 库。编译过程中如果报错找不到 Qt5Core大概率是CMAKE_PREFIX_PATH写错了或者路径下的lib/cmake文件缺失。安装完成后在终端启用环境变量后执行qtcreator如果能正常启动说明 Qt Creator 已经被你掌握了——从源码编译的想怎么改就怎么改不用再看官方安装包的脸色。提示Qt Creator 编译后会安装到/opt/Qt/5.15.2/gcc_64/bin/和 qmake 放在同一目录方便后续环境变量统一管理。如果你希望改名为qtcreator-custom可以在 make install 后手动改一下二进制文件名。5. 环境集成与项目构建验证一切真的能用5.1 用自编译 Qt 创建一个测试工程环境搭好不等于万事大吉必须实际跑一个项目测试链路。创建测试工程mkdir ~/testapp cd ~/testapp cat main.cpp EOF #include QApplication #include QLabel int main(int argc, char *argv[]) { QApplication app(argc, argv); QLabel label(ARM UOS Qt 5.15.2 编译验证成功); label.resize(400, 200); label.show(); return app.exec(); } EOF创建工程文件testapp.proQT core gui greaterThan(QT_MAJOR_VERSION, 4): QT widgets TARGET testapp TEMPLATE app SOURCES main.cpp执行构建qmake make ./testapp如果窗口正常显示文字并且移动窗口没有明显卡顿恭喜整个源码编译链路已经打通。5.2 同时存在的两套 Qt如何处理环境冲突UOS 系统已经带有一套 Qt你自己编译了一套 Qt。运行.deb格式安装的软件不会受影响因为它们链接的系统 Qt 路径是/usr/lib/...而你编译的 Qt 在/opt/Qt/...两者在文件系统层面是隔离的。真正的坑在于终端里同时存在两个 qmake。执行which qmake看看实际调用的哪个。如果显示/usr/bin/qmake而你希望用/opt/Qt/5.15.2/gcc_64/bin/qmake记得确认/etc/profile.d/qt515.sh里的 PATH 是否排在前面。一个保险的办法是给测试工程强制指定 qmake 路径/opt/Qt/5.15.2/gcc_64/bin/qmake5.3 解决 Qt 平台插件加载失败问题在实际 UOS 设备上程序编译好但双击运行时提示could not find or load the Qt platform plugin xcb这是最常见的问题。原因很直白启动程序时Qt 找不到 xcb 插件的位置。解决办法是把插件路径明确告诉 Qtexport QT_QPA_PLATFORM_PLUGIN_PATH/opt/Qt/5.15.2/gcc_64/plugins/platforms ./testapp如果已经设了这个环境变量还是报错检查编译时 xcb 相关依赖是否完整在 X11 桌面环境下运行以下命令来诊断ldd /opt/Qt/5.15.2/gcc_64/plugins/platforms/libqxcb.so ldd /opt/Qt/5.15.2/gcc_64/lib/libQt5XcbQpa.so.5如果输出里有not found就是对应的系统库缺失回去补装。在线环境装不上就用 ISO 里的安装包国产环境经常遇到离线安装场景UOS 的本地软件包目录在/var/cache/apt/archives/原来装过的安装包都在那里离线部署时可以手工从这里面找。6. 实战中的坑与排查手册比教程更值得收藏的部分6.1 configure 阶段报错缺依赖怎么办configure 报错信息五花八门但九成是“找不到某个头文件或库”。切记不要看到报错就直接重新执行 configure先定位缺什么。我遇到的最典型的是ERROR: xcb not found.排查过程dpkg -l | grep xcb如果发现没有libxcb-xkb-dev就装上。然后重新跑 configure。如果已经安装了但 configure 仍说找不到大概率是因为 pkg-config 的路径没有包含系统库export PKG_CONFIG_PATH/usr/lib/aarch64-linux-gnu/pkgconfigARM 设备上 pkg-config 路径经常和 x86 不同这一步能解决 50% 以上的假性“找不到库”问题。6.2 make 阶段内存不足编译 Qt 这种超大项目内存不足的表现是进程被系统 OOM内存溢出杀死终端输出Killed有时候连错误信息都没有。之前在一台 4GB 内存的 ARM 开发板上编译-j4直接 OOM反复到最后才意识到是并行度问题。解决办法是降到-j2并增加 Swap。添加 Swap 的命令sudo fallocate -l 8G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile编译完成后如果不需要 Swap可以sudo swapoff /swapfile sudo rm /swapfile清理掉。6.3 程序运行崩溃在 libQt5Core 内编译好的应用在某些设备上运行时突然段错误而拿到本机编译的机器上又是好的。这类问题通常是二进制兼容性引起的比如编译时用了旧设备上不存在的 CPU 指令。处理方法是在 configure 时加上通用指令集参数-QMAKE_CFLAGS-marcharmv8-a \ -QMAKE_CXXFLAGS-marcharmv8-a这里用armv8-a是 ARM 64 位的通用基准不做特殊指令扩展。这样产生的二进制在任何 ARMv8 设备上都能运行。如果你对目标设备非常了解可以尝试-marchnative但要注意部署环境如果目标设备不支持编译机器的扩展指令集跑起来直接非法指令。6.4 Qt Creator 启动后界面模糊UOS 默认开启了字体缩放和屏幕缩放而源码编译的 Qt Creator 可能对高分屏缩放比例不敏感导致界面模糊。解决办法是设置环境变量export QT_AUTO_SCREEN_SCALE_FACTOR1 export QT_SCALE_FACTOR1.5QT_AUTO_SCREEN_SCALE_FACTOR1让 Qt 自动根据屏幕 DPI 调整缩放比例QT_SCALE_FACTOR是手动指定倍率。具体设备的具体参数需要根据实际显示效果反复调。6.5 常见问题速查表整理一张我实际踩过的坑速查表方便你直接对照现象可能原因解决方案configure 报 xcb not foundxcb 开发库缺失或 pkg-config 路径不对安装 libxcb* 库设置 PKG_CONFIG_PATHmake 时进程被杀内存不足降低 -j 并行度增加 Swapqmake 版本不对系统自带 qmake 优先级更高调整 PATH 顺序或直接用绝对路径程序提示找不到平台插件 xcbQT_QPA_PLATFORM_PLUGIN_PATH 未设置显式设置插件路径应用运行崩溃在 Qt 库内指令集差异或 Qt 配置问题编译时指定通用架构参数Qt Creator 界面模糊高分屏缩放未适配设置 QT_AUTO_SCREEN_SCALE_FACTOR6.6 调试符号与日志开关编译完成后如果后续要排查崩溃建议开启 Qt 的日志输出环境变量export QT_DEBUG_PLUGINS1运行程序时终端会输出每个平台插件加载的详细信息哪个插件加载了、加载失败的原因是什么一目了然。这个变量在我们适配自己写的平台插件时帮了大忙。加上-debug-and-release编译的库配合gdb崩溃现场能把 Qt 内部每一层调用逻辑都摊开来看。7. 一些收尾的小经验这次以 ARM 架构 UOS 为平台从源码编译 Qt 5.15.2 并定制 Qt Creator 的整个流程前前后后折腾了大概三天。回头看最大的感触是源码编译这件事本身并不难难的是理解每一步操作背后系统是怎么运作的。比如 configure 阶段明明可以加--help查看全部参数文档但大多数人不会去逐条读又比如-no-opengl这个看似“阉割”的参数实际上在国产 ARM 设备上反而是保证稳定性的最佳选择。如果你准备在 UOS 或其他国产操作系统上搭建 Qt 开发环境我给个建议先花半小时理清项目到底需要哪些模块再看这篇博客把环境准备做扎实。编译过程一定会遇到报错不要急着重跑先看日志、查依赖、再看 pkg-config 路径逐个击破。最后分享一个小技巧编译好的 Qt 目录建议打一个压缩包存起来tar -czf Qt-5.15.2-arm64.tar.gz /opt/Qt/5.15.2后续要在其他同架构 UOS 机器上部署环境时直接解压到对应路径再配好环境变量10 分钟就能再造一个开发环境省去一整晚的编译等待。这条经验是我在部署第二台设备时实实在在体会到的便利。希望这篇记录能帮你少走几段弯路。
阅读完成 · 觉得有帮助？
