ARM Linux下源码编译Qt 5.15.2实战:从依赖配置到打包分发

发布时间:2026/8/31 2:55:59
ARM Linux下源码编译Qt 5.15.2实战:从依赖配置到打包分发 简介本资源是专为国产操作系统UOS 20适配的Qt 5.15.2完整编译产物面向嵌入式开发、信创适配工程师及ARM平台Qt应用开发者解决在华为鲲鹏等ARM架构下Qt源码编译耗时长、依赖复杂、环境配置易出错等实际难题。压缩包为ZIP格式共包含2000个头文件.h涵盖OpenGL扩展支持如qopenglextensions.h、本地化数据qlocale_data_p.h、日志与调试辅助valgrind_p.h、日历模块qromancalendar_data_p.h及多版本OpenGL函数封装4.2–4.5兼容性头文件全面支撑Qt核心模块调用与跨版本开发。资源大小75.18MB结构规整解压后设置环境变量即可直接集成到UOS ARM项目中使用。目前已有613人学习下载提供开箱即用的编译成果显著降低国产化平台Qt开发门槛节省数小时至数天的交叉编译与调试时间。1. 为什么放弃系统自带的Qt选择在ARM上从源码编译5.15.21.1 项目具体场景和目标我手头这台设备是飞腾FT-2000/4小主机4核CPU内存16GB系统装的是统信UOS 20桌面版ARM64主要用于跑一些基于Qt的工业控制界面和上位机程序。拿到机器第一天我就发现一个很现实的问题系统软件源里自带的Qt只有一个5.11.3而且不是完整版本好多模块比如Qt Charts、Qt Data Visualization都没有更麻烦的是某些新项目用了5.15才有的接口直接在系统源上编译根本过不去。刚开始我想偷懒打算直接从网上下一个别人编好的ARM版Qt 5.15.2离线包来用但试了几次发现很多包的出处不明有的解压出来缺平台插件有的连libQt5Core都没有装上之后程序起不来也不知道该怪谁。后来索性自己花两天时间从源码完整编译了一套安装到/opt/Qt5.15.2再把安装目录打包成压缩文件拿到另一台同架构的UOS20机器上解压就能直接用省去了到处找包的麻烦。这篇记录主要写给三类人参考一类是设备性能还过得去、想自己编译一版完整Qt 5.15.2的开发者一类是拿到现成包后不知道怎么安装、不知道如何验证包是否适用于自己机器的运维人员还有一类是正在ARM Linux环境上被“platform plugin xcb加载失败”“QtWebEngine编不过”这类问题折磨的倒霉蛋。核心关键词就四个Qt5.15.2、Linux ARM架构、源码编译、UOS20。1.2 原生编译还是交叉编译的选型逻辑动手之前必须先想清楚一个问题在ARM设备上装Qt到底是原生编译还是交叉编译交叉编译的典型场景是设备本身性能弱比如只有1GB内存的嵌入式板子跑完整Qt编译直接卡死或者你拿到的是开发板交叉工具链和环境依赖都是厂商配好的目标设备没有编译能力。这种时候你必须在x86的PC上用aarch64-linux-gnu-g编出目标系统的Qt再把整个sysroot同步到板子上工程量很大每个第三方库都要单独交叉编译一遍遇到依赖问题排查成本极高。我这边的情况完全不同。设备虽然只是4核心但内存有16GBUOS 20的系统里自带gcc 8.3和Qt 5.15.2的编译器要求完全匹配。原生编译有几个明显优点第一不需要为每一个依赖库单独搭建交叉编译工具链第二Qt的configure脚本自己会检测系统环境不会遇到“x86上验证通过、ARM上跑不起来”的偏移问题第三编出来的Qt库就是目标机原生库后续部署应用不需要考虑交叉工具链的ABI兼容。原生编译也不是没有代价代价主要是编译时间。Qt 5.15.2完整源码解压后有几十万个文件不开WebEngine模块的前提下四核CPU全速编译大概需要40到60分钟开启WebEngine的话直接往半天以上跑中间宕机一次就得重新来。如果你的设备只有2GB内存我的建议还是别硬杠原生编译老老实实交叉编译或者找现成包。1.3 编译一次、打包多机分发的可行性这个项目能打包成一个“已编译好的包”分发原因在于Qt安装目录的设计本身是自包含的。当你指定了-prefix /opt/Qt5.15.2之后编译出来的动态库、头文件、插件、QML模块、翻译文件和mkspec都会集中在一个目录里不依赖系统软件源里的Qt。这意味着只要目标机和编译机是同一CPU架构、同一个足够新版本的glibc把整个目录用tar压缩打包到另一台机器上解压到相同路径基本上可以跑起来。不过我打包时踩过一个教训如果第一台机器上的Qt是用系统自带的OpenGL库编译的第二台机器如果显卡驱动或者Mesa版本差异太大xcb插件可能能加载但渲染出来是黑的。所以打包后不能只看“库能链接”就判定成功必须实际跑一个带界面渲染的示例程序验证。这一点后面第5章会专门展开。2. 编译前先理清资源账依赖包、磁盘空间和线程数规划2.1 基础工具链的版本确认很多ARM板子上默认只装了精简系统g都没装。开始编译之前先把工具链查一遍缺啥补啥gcc --version g --version make --version perl -v python3 --versionUOS 20基于Debian 10体系系统软件源自带的是gcc 8.3对Qt 5.15.2来说完全够用。如果输出结果里g不存在先安装build-essential。这里特别提醒不要手贱装gcc-9或者切换默认编译器Qt 5.15.2在gcc 9下也能编过但是某些第三方模块比如老的Qt Virtual Keyboard会对版本比较敏感没必要给自己添堵。还需要确认Perl和Python是否到位。Qt的构建流程里有不少脚本依赖它们Perl版本小于5.14会出现问题。我会在装完依赖后执行一次简单的版本检查输入输出记录到文本文件里方便后期排查问题。2.2 依赖包安装在ARM devboard环境下最省事的做法是直接apt安装。把下面这一串装好能避免configure阶段90%的报警sudo apt update sudo apt install -y build-essential perl python3 git gperf bison flex \ libgl1-mesa-dev libfontconfig1-dev libfreetype6-dev libx11-dev \ libxkbcommon-dev libxkbcommon-x11-dev libxcb1-dev libxcb-util-dev \ libxcb-image0-dev libxcb-keysyms1-dev libxcb-randr0-dev \ libxcb-render-util0-dev libxcb-shape0-dev libxcb-shm0-dev \ libxcb-sync-dev libxcb-xfixes0-dev libxcb-xinerama0-dev \ libxcb-xkb-dev libxcb-icccm4-dev libssl-dev libudev-dev \ libsqlite3-dev libts-dev libpulse-dev libcups2-dev我逐一说明下这些包的作用。libgl1-mesa-dev提供OpenGL开发头文件Qt的GUI渲染和QML场景图离不开它libxkbcommon和libxcb系列是Qt xcb平台插件的基础缺失时configure显示xcb为no编译完的Qt能装但界面上不来libfontconfig1-dev和libfreetype6-dev负责字体匹配和字形渲染中文场景下务必装上否则中文显示成豆腐块的概率极高gperf、bison、flex是Qt的一些代码生成器需要调用的工具编译Qt 3D特别依赖它们。如果你的设备不能联网比较笨但有效的办法是找一台同版本UOS20的机器用apt download把以上deb包全部下载下来再用dpkg -i *.deb离线安装。ARM包的deb文件名里通常会有arm64字段注意不要下成amd64了。2.3 磁盘和内存安排这部分经常被忽略等编译到一半报磁盘满才回头救非常浪费时间。Qt 5.15.2源码包qt-everywhere-src-5.15.2.tar.xz解压后大约3GB编译过程中还会产生约5GB的中间文件再加上安装目录里面库文件和头文件占用的1.5GB以上建议保留至少12GB空闲空间。我是直接放在/home/下的因为UOS的系统盘有时候分区比较小/根目录只有15GB的话很容易爆掉。内存是更值得注意的问题。Qt多个模块并行编译时每个g进程可能吃掉1GB甚至更多内存四核CPU开-j416GB内存刚好能撑住8GB内存就会频繁触发交换严重时直接被OOM killer杀掉进程。如果你的设备像常见的开发板一样只有4GB内存务必先创建一个swap文件sudo fallocate -l 8G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile线程数最终我建议不要盲跑make -j$(nproc)因为nproc返回的物理核数不一定等于可用的编译并发数。以我的FT-2000/4为例确实是4核-j4没问题但如果你用的是带超线程的ARM处理器实际并发能力反而没那么高。保守公式是并发数 内存GB数 / 216GB内存就给-j48GB内存就给-j2宁可多编一会儿省得返工。3. configure参数这样配才能一次性画出可用的图形平台3.1 源码下载与目录约定从Qt官网的源码镜下载qt-everywhere-src-5.15.2.tar.xz文件大约500MB左右。下载完先校验一下sha256我吃过亏下载中断或镜像损坏导致配置到一半出现莫名其妙的语法错误。校验值在官网发布页面能查到用sha256sum核对一下再解压。目录结构我建议这样规划/home/build/qt-everywhere-src-5.15.2源码目录/opt/Qt5.15.2安装目录/home/build/qt-build单独建一个空目录作为构建目录Qt 5.15后续版本支持影子构建也就是源码目录保持干净在另一个目录里跑configure和make。这样做的好处是如果某次配置失败直接把构建目录删掉重来就行不用重新解压源码省不少时间。有的教程直接在源码目录里configure一旦缓存脏了就得反复make distclean体验很差。3.2 configure参数详解与实际配置进入构建目录后执行这样一段cd /home/build/qt-build /hommed/build/qt-everywhere-src-5.15.2/configure \ -prefix /opt/Qt5.15.2 \ -release \ -opensource \ -confirm-license \ -platform linux-g \ -xcb \ -eglfs \ -linuxfb \ -fontconfig \ -system-freetype \ -qt-zlib \ -qt-libpng \ -qt-libjpeg \ -no-openssl \ -no-feature-vnc \ -skip qtwebengine \ -make libs \ -make tools \ -nomake examples \ -nomake tests每个参数的意思我掰开来讲。-prefix /opt/Qt5.15.2决定了最终安装位置。默认不指定的话会装到/usr/local/Qt-5.15.2不是不行但后续想卸干净很麻烦。自定义前缀目录的好处是自包含一个目录就是一个完整的Qt环境。我习惯把Qt装在/opt下需要权限控制就单独给这个目录设所属用户。-release只编译发行版本不生成调试库。开发机如果还要用gdb调试可以考虑加-debug-and-release不过这会把库数量翻倍ARM机上很费磁盘。我最终选了纯release因为编译目标本来就是分发到现场设备上跑。-opensource和-confirm-license用于确认开源许可协议不用交互。-platform linux-g是指定qmake的mkspec。很多人以为交叉编译才需要改这个其实原生编译时它同样重要它告诉Qt使用本机g作为编译器和链接器。在ARM Linux上只要用这个默认mkspecQt会自动检测aarch64不需要额外指定linux-aarch64-gnu-g。-xcb这个参数万分关键。UOS 20桌面环境用的是X11窗口系统Qt图形程序必须通过xcb平台插件和X server通信。加了-xcbconfigure才会主动检查libxcb相关依赖并在plugins/platforms/里生成libqxcb.so。很多网上找的预编译包缺这个插件装上后跑程序报“could not find or load the Qt platform plugin xcb”就是当初编译时没有启用或者编译环境缺依赖。-eglfs和-linuxfb是为无显示服务器的嵌入式场景准备的。虽然UOS桌面用不上但如果你以后要把程序挪到一个没有X11的ARM开发板上这两个插件可以让你用-platform eglfs或-platform linuxfb直接操作framebuffer显示。加上它属于锦上添花编译开销很小。-fontconfig、-system-freetype决定字体系统采用操作系统的fontconfig和freetype。中文界面渲染是否正常很大程度就靠它们。如果强制Qt自己编译一个freetype反而容易出问题。-qt-zlib -qt-libpng -qt-libjpeg使用Qt源码自带的zlib/png/jpeg实现而不是依赖系统库。好处是避免系统库版本差异导致兼容问题坏处是包体会变大一些在ARM设备上这点容量无所谓建议保留。-no-openssl当初纠结了一下。如果应用不需要访问HTTPS网络接口这个参数能绕开系统OpenSSL版本不匹配的问题。如果你的程序要联网一定要改成-openssl-linked并且确保前面已经安装了libssl-dev否则Qt的QSslSocket功能将不可用HTTP请求在TLS握手阶段会直接失败。-no-feature-vnc关闭VNC相关功能纯粹压缩编译时间一般用不上VNC远程桌面协议就直接关。-skip qtwebengine是最影响编译时长的开关之一。Qt WebEngine基于Chromium在ARM上编译不仅需要额外的Clang、GN工具链还非常吃内存16GB机器很容易编到一半被OOM干掉。我不需要浏览器内核所以直接跳过。如果你确实需要QWebEngine建议换一台大内存机器单独编或者找官方提供的对应架构包不要和基础Qt混在一个构建流程里。-make libs -make tools -nomake examples -nomake tests的意思是只编译Qt的库和开发工具比如qmake、moc、rcc、uic不编译example和test减少大量构建量。全套examples在ARM上编译非常拖时间而且绝大多数组件正常开发根本用不上。配置完成后不要急着make先打开生成在构建目录里的config.summary文件看到这样几段才算通过Qt 3D ................. yes Qt Charts ............. yes ... xcb ................... yes ... EGLFS ................. yes LinuxFB ............... yes最重要的一条是xcb ................... yes如果显示no说明前面某个libxcb依赖没装齐。不要硬着头皮继续make按CtrlC退出安装缺少的依赖然后删掉整个构建目录重新configure。不重来就会出现Qt库装好了但没生成xcb插件的情况后面只能补编译整个qtbase更麻烦。3.3 make与make installconfigure通过后编译指令很简单make -j4 21 | tee build.log建议把日志输出到文件里因为槽点往往藏在几千行中间。-j4线程数按前面内存公式来不要加太多。如果编译过程中途报错先用tail -50 build.log看尾部错误再配合grep Error查完整错误列表。编译时间在4核16GB的机器上不开WebEngine大概40分钟左右。编译完成后执行make install如果之前没给/opt/Qt5.15.2目录调整权限这里需要sudo。我最后悔的就是第一次用sudo make install后来发现/opt/Qt5.15.2整个目录的属主是root自己编译应用时经常遇到权限边缘问题。建议提前创建目录并改属主sudo mkdir -p /opt/Qt5.15.2 sudo chown -R $USER:$USER /opt/Qt5.15.2然后再以普通用户身份执行make install这样整个Qt目录的所有者全是当前用户后续往plugins里拷输入法插件、修改mkspecs都方便得多。3.4 环境变量配置与验证安装完成后为了让终端能直接找到qmake写一个环境变量脚本/etc/profile.d/qt5.15.shexport QTDIR/opt/Qt5.15.2 export PATH$QTDIR/bin:$PATH export LD_LIBRARY_PATH$QTDIR/lib:$LD_LIBRARY_PATH export QT_PLUGIN_PATH$QTDIR/plugins export QT_QPA_PLATFORMxcb其中QT_QPA_PLATFORMxcb是提醒应用默认选择xcb平台如果是纯命令行环境跑无界面程序改成QT_QPA_PLATFORMoffscreen反而更合适。验证安装是否成功source /etc/profile.d/qt5.15.sh qmake -query QT_VERSION qmake -query QT_INSTALL_PREFIX正常会分别输出5.15.2和/opt/Qt5.15.2。4. 编译过程遇到最多的三类问题xcb依赖、内存不足和WebEngine4.1 xcb相关依赖缺失的典型症状这是我第一次编译时踩的坑印象特别深。当时configure命令里也加了-xcb但没装全libxcb系列包configure跑到一半没有直接报错只在最后输出一份长长的summary。我没仔细看就接着make编译倒是成功了结果安装完成后运行一个简单的窗口程序直接提示This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.再看plugins/platforms/目录发现根本没有libqxcb.so。回到config.summary里查发现xcb这一行是no原因是缺libxcb-xinerama0-dev。我重新安装这个包、清空构建目录再configurexcb才变yes。这个坑的教训是configure期间凡是看到和xcb相关的warning一律要当成error处理不要心存侥幸。Basic XLib functionality test failed、The xcb library version may present problems这类提示都说明系统缺对应的开发包提前装齐能省一个多小时。4.2 内存不足导致的OOM中断第二次编译采用-j4构建Qt Declarative模块时CPU风扇狂转系统响应变慢紧接着进程直接消失只有shell里留下一段Killed查看/var/log/syslog能发现OOM killer记录。原因是多条编译线程同时进行代码生成和编译每个gcc进程占用内存超过2GB16GB内存很快被吃光。解决方式是先补swap再降并发sudo fallocate -l 16G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile然后把并发降到-j2或者-j1对4核机器来说编译时间会明显拉长但至少能跑完。另一个小技巧是只编译需要的模块比如我知道自己不需要WebEngine在第3章配置时就通过-skip跳过了这直接减少了一大块最吃内存的编译量。4.3 QtWebEngine编译失败与模块裁剪如果试图在ARM设备上编译包含QtWebEngine的完整Qt 5.15.2很可能会在几十个模块都已编完后卡在QtWebEngine的ninja构建环节。常见错误包括error: use of undeclared identifier、ninja: build stopped: subcommand failed根因往往是Clang版本不匹配或者系统库不匹配。我实际遇到的是在aarch64的Debian 10环境下QtWebEngine要求的Chromium构建依赖与系统自带的LLVM版本冲突。如果只是需要一个包含浏览器内核的Qt环境有两条路第一按Qt官方文档安装对应版本的Clang并配置-webengine模块第二像我一样在配置阶段直接-skip qtwebengine后期如果确实有WebEngine需求再单独构建这一个模块。反正分开编的隔离性更好基础Qt出问题的概率也更低。4.4 编译器版本兼容性Qt 5.15.2对C标准要求不算激进但Qt 3D等模块里已经用到了C17特性。Debian 10/UOS20自带的gcc 8.3没问题但如果你手头是更老的gcc 6或者gcc 7比如某些debian 9移植板编译Qt 3D时就有可能在模板推导上报错。如果碰到这类情况安装更新的gcc并指定CXX变量sudo apt install g-8 export CXXg-8 export CCgcc-8再重新configure。注意设置环境变量后要彻底清掉旧构建目录否则缓存里还是旧编译器。4.5 安装权限问题很多人习惯sudo make install装完后用root编译应用没有任何问题但一旦涉及到给应用目录拷贝Qt库文件或者把Qt打包发给别人就会出现文件属主全是root的情况。如果是个人开发机问题不大但我觉得交叉部署时最好还是统一用普通用户管理Qt目录避免后续复制、删除、覆盖都得sudo。建议在configure之前就先创建好安装目录并调整属主而不是等install时临时创建。5. 安装后的QPA运行验证让Qt程序在UOS20桌面上正常显示5.1 为什么UOS桌面上的QPA默认走xcbUOS 20桌面版使用的是深度桌面环境DDE底层窗口协议是X11。Qt应用在启动时会加载一个平台插件这个插件决定了它用哪种方式和显示服务器通信。X11环境下最合适的就是xcb插件。如果你在编译时把xcb正确编出来了应用运行时会自动探测到plugins/platforms/libqxcb.so并加载。一个最常见的报错是qt.qpa.plugin: Could not find the Qt platform plugin xcb in 这里先说清楚出现这句话有两种情况一是插件文件不存在二是插件文件存在但依赖的动态库缺失导致加载失败。很多人看到提示就以为路径不对其实往往是第一种还是第二种需要区分。我先用ls确认文件在不在ls -l /opt/Qt5.15.2/plugins/platforms/libqxcb.so文件存在的话再用ldd检查依赖ldd /opt/Qt5.15.2/plugins/platforms/libqxcb.so | grep not found有not found输出说明系统缺少某个libxcb相关的运行库这个库很可能不是开发包而是运行库需要额外安装。不要试图把缺失的so手工从其他机器拷过来版本不一致反而会引发更奇怪的问题。5.2 用QT_DEBUG_PLUGINS定位插件加载失败如果ldd查不出问题启用Qt的插件加载调试输出QT_DEBUG_PLUGINS1 ./myQtApp运行后日志会列出每个被尝试加载的插件和加载失败原因。比如有一次我看到QFactoryLoader::QFactoryLoader() checking directory path /opt/Qt5.15.2/plugins/platforms ... Cannot load library /opt/Qt5.15.2/plugins/platforms/libqxcb.so: (libxkbcommon-x11.so.0: cannot open shared object file: No such file or directory)这行已经指得很明确了缺libxkbcommon-x11.so.0。在UOS20上安装libxkbcommon-x11-0包即可注意不是-dev版本运行库是0结尾然后程序就能正常启。整个过程的核心思路是出错时不要只看Qt最上层那句“platform plugin not found”要从最下面一行具体库缺失信息开始排查。5.3 中文字体与渲染的检查点安装完Qt后先别急着跑复杂界面写个最简单的窗口程序测一下字体。Qt字体走的是fontconfig机制前面configure使用-fontconfig -system-freetype后会直接使用系统字体库。如果在UOS20上进入桌面程序里显示中文正常说明配置没问题如果显示成方框需要先安装中文字体包sudo apt install fonts-noto-cjk同时检查/etc/fonts/fonts.conf是否存在。Qt程序启动时会通过QFontDatabase读取系统字体配置如果应用里强制指定的字体不存在会fallback到一个替换字体这时候就可能出现中文乱码。我在实际项目里遇到过UOS自带的文泉驿字体没装干净Qt应用中文显示空白的情况最后是重装字体并重跑fc-cache -f解决的。6. 已编译好的Qt 5.15.2如何整理、分发和落机校验6.1 打包前清点目录编译安装完成后除了/opt/Qt5.15.2目录还要注意构建目录里残留了大量临时对象文件这些不能打进发布包。Qt安装目录从结构上包含以下几个核心子目录bin/qmake、moc、rcc、uic等开发工具lib/全部动态库plugins/平台插件、图片格式插件、输入法插件等qml/QML模块和导入包include/开发头文件mkspecs/编译器规格文件打包前我建议把doc/目录删掉如果需要离线文档另留一份但打包给他人时不必背这么大体积。然后压缩cd /opt tar -cJf qt-5.15.2-arm64-uos20.tar.xz Qt5.15.2这样得到的压缩包通常不到200MB因为Qt的动态库已经strip过。tar.xz解压后依然是完整目录结构落机后直接放到/opt下即可。不需要做成deb或rpm包因为这种自包含的绿色目录风格在嵌入式/桌面ARM设备上最不容易产生依赖冲突。6.2 目标机器上的安装校验在另一台UOS20 ARM机器上解压后先不要急着配环境变量按顺序做三个检查。第一个检查系统架构uname -m必须输出aarch64这是硬条件。第二个检查glibc版本。我打包时使用的Qt是UOS20环境和glibc 2.28编译的如果目标机的glibc比2.28还老比如一些老嵌入式发行版只有2.17动态库加载时会报GLIBC_2.28 not found。用这个命令确认strings /lib/aarch64-linux-gnu/libc.so.6 | grep GLIBC_2.28第三检查Qt自身能否运行export LD_LIBRARY_PATH/opt/Qt5.15.2/lib:$LD_LIBRARY_PATH /opt/Qt5.15.2/bin/qmake -query QT_VERSION正常输出5.15.2。如果输出正常再用ldd查一下核心库ldd /opt/Qt5.15.2/lib/libQt5XcbQpa.so.5 | grep not found有not found就补齐对应的系统运行库没有就说明依赖干净。这一步十分可靠我基本用它代替所谓的“开机测试”。6.3 已编译包为什么不适用所有ARM板子预编译包有适用范围不能因为都是AArch64就直接拿来用。第一个坑是libGL的差异。如果Qt在编译机上是链接到桌面版Mesa的OpenGL库目标机如果是只有软件渲染的嵌入式GPUeglfs可能无法初始化但xcb模式下只要Mesa的正常软件渲染提供libGLESv2.so大多数应用还能跑。第二个坑是目标机的/lib路径结构和缺的系统运行库。UOS20的lib路径是/lib/aarch64-linux-gnu/有些精简系统没有libpcre2、libdouble-conversion这类Qt间接依赖的库解压后还需要apt补齐。我遇到过最麻烦的一次目标机缺了libxcb-cursor0而系统源里没有这个单独包最后只能从上游Debian仓库手工下载arm64的deb包装上。所以我打包说明里都会写清楚本包适合UOS20/Debian 10 arm64环境glibc≥2.28需要X11桌面不支持纯命令行无显示服务器场景。这些边界条件写清楚能省掉一堆后续沟通成本。6.4 应用部署时的动态库梳理与qt.conf技巧编译好的Qt安装到目标机之后接下来就是把自己写的本文还有配套的精品资源点击获取