简介：面向 Linux 桌面应用开发者，资源定位为 Qt 5.9.9 在 CentOS 7.6 x64 环境下静态编译的完整库包，支持 XCB 图形平台，编译出的图形界面程序通过 ldd 检查时不再依赖 Qt 运行库，可显著简化程序分发与部署。包体约 197.4MB，包含近 2000 个文件，以 Qt 头文件、.a 静态库、.pri/.prl/.cmake 等构建配置为主，同时带有 .qm 翻译文件与辅助工具脚本，Core、Gui、Widgets、Network、QML 等常用模块的接口声明和链接描述都比较齐全。编译环境为 GCC 4.8.5、glibc 2.17，配置命令参考了 -static -qt-xcb 等关键参数，适合需要快速获得静态 Qt 环境或二次编译的开发者。已有 569 人学习，资源内提供大量类型定义与接口声明，可直接用于裁剪、升级或对照排查链接问题，节省从源码自行编译的耗时。
1. 先把这个 qt-5.9.9 静态包拆开：它解决的是“老 Linux 上跑 Qt GUI”的问题
如果你手上的 Linux 还是 gcc 4.8.5 / glibc 2.17 那一代，却要交付一个 Qt GUI 客户端，最常见的坑是：目标机缺 Qt 运行库、新版依赖装不上、交叉编译出来的二进制一过去就报错。qt-5.9.9-gcc485-libc217-static-qt-xcb.tar.gz 就是为这个场景准备的——Qt 5.9.9 按 gcc 485 体系静态编好，xcb 平台插件也一并链进去。适合两类人：一类要在老系统上出可用界面，另一类是维护工控机、不想在目标机装任何 Qt 依赖的人。注意它是“离线静态构建包”，不是免安装包，理解这条边界，后面能少走弯路。
2. 拆包先看布局：static-qt-xcb 里的关键目录与 ABI 含义
2.1 先别急着解压，先摸清归档里的“前缀”
老手拿到这种 tar.gz 都不会直接tar -xzf，因为压缩包里可能自带一层顶层目录，也可能没有。少了这层前缀，所有路径会散落到当前目录，后面解包成一堆 bin、lib、mkspecs，收拾起来相当难受。先看顶层结构：
# 列出归档内所有条目，去掉第一个斜杠后面的部分，得到顶层目录名 tar -tzf qt-5.9.9-gcc485-libc217-static-qt-xcb.tar.gz | sed 's#/.*##' | sort -u这条命令的原理是：tar -t只列出条目不展开文件，sed 's#/.*##'把每个路径从第一个斜杠处截断，最终输出所有条目的顶层目录名。用sort -u去重后，如果看到的是qt-5.9.9/这样的统一前缀，解压时就应该先建一个父目录，再让包里的前缀落进去：
# 建一个统一安装前缀，避免散落当前目录 mkdir -p /opt/qt-static tar -xzf qt-5.9.9-gcc485-libc217-static-qt-xcb.tar.gz -C /opt/qt-static ls /opt/qt-static/按这类静态 Qt 包的常见布局，解压后你会看到表 1 所列的几块内容。这里只列路径和作用，不预先假设文件数，因为不同构建脚本产出的仓库略有差异。
| 路径 | 内容 | 静态构建里的作用 |
|---|---|---|
| bin/qmake | qmake 可执行文件 | 生成 Makefile，同时携带 Qt 的安装前缀、版本信息 |
| lib/ | libQt5Core.a、libQt5Gui.a、libQt5Widgets.a 等 | 静态链接时直接拉进可执行文件的归档库 |
| plugins/platforms/ | xcb 相关插件或其静态归档库 | GUI 启动时加载的 xcb 平台插件 |
| mkspecs/ | qmake 的编译配置 | 决定默认 C++ 标准、编译器参数和链接选项 |
| include/ | Qt 头文件 | 编译时需要的 API 声明 |
解包之后，第一件事是验证 qmake 认识自己，而不是急着编译：
# 查看静态 Qt 自带的前缀和插件路径 export QTDIR=/opt/qt-static/qt-5.9.9 export PATH=$QTDIR/bin:$PATH qmake -query QT_INSTALL_PREFIX qmake -query QT_INSTALL_PLUGINSQT_INSTALL_PREFIX输出的是这个包预设的安装路径。QT_INSTALL_PLUGINS则是插件目录，静态包里这个路径可能指向归档内的 plugins 目录，也可能是一个构建机上残留的源码目录。如果输出里出现陌生路径，后文编译时就要用QMAKE_INSTALL_PREFIX或QT_PLUGIN_PATH把它纠正过来。
2.2 gcc485 和 libc217，决定产物能否在目标机启动的两个硬指标
包名里的gcc485指 gcc 4.8.5，libc217指 glibc 2.17。这两个数字不是随便写的，它决定了这套静态库的 ABI 下限。Linux 上的 glibc 有一个典型规则：在旧 glibc 上编译的二进制，可以拿到新 glibc 系统上运行；反过来则不行。因为在 glibc 2.17 机器上，找不到新版本才引入的GLIBC_2.18、GLIBC_2.27这类符号，动态加载器会直接拒绝启动。
gcc 4.8.5 的意义也在libstdc++符号版本上。C++ 运行时的符号带GLIBCXX_3.4.19之类的版本号，gcc 版本越新，符号版本号越高。用新 gcc 在构建机上编出来的静态 Qt，静态库本身可以不依赖libstdc++.so，但目标机上如果跑的是老libstdc++.so，一旦程序里用了新符号，照样崩。
所以判断这套包能不能用，要落到具体符号检查，而不是只凭文件名。常见做法是用objdump查看 Qt 核心静态库依赖的最高 glibc 符号版本：
# 列出 libQt5Core.a 里引用到的 GLIBC_ 符号版本，取最大值 objdump -T /opt/qt-static/qt-5.9.9/lib/libQt5Core.a \ | grep -oE 'GLIBC_[0-9.]+' \ | sort -V | tail -n 5objdump -T输出共享库或目标文件的动态符号表；grep -oE只提取形如GLIBC_2.17的版本标记；sort -V按版本号排序；tail -n 5看最高的几个版本。如果结果没有超出GLIBC_2.17，那这套库就能在你的老目标机上安全落地。若出现GLIBC_2.28，说明包名与内容不符，后续所有编译都是在浪费工时。
2.3 验证库能用：用最小 QWidget 程序试链接
不要一上来就编译大工程。先写一个最小的 QWidget 窗口，验证 qmake 配置、静态库、xcb 插件三件事是否同时成立。项目文件很小，但已经覆盖了核心 GUI 路径。
// main.cpp：最小验证程序，只弹一个窗口 #include <QApplication> #include <QLabel> int main(int argc, char *argv[]) { QApplication app(argc, argv); QLabel label(QStringLiteral("static check")); label.resize(320, 200); label.show(); return app.exec(); }配套的项目文件：
# static_check.pro QT += core gui widgets TARGET = static_check TEMPLATE = app CONFIG += c++11 SOURCES += main.cpp编译命令很简单，但要注意先在当前 shell 里把 PATH 切到 Qt 包的 bin 目录：
mkdir -p /tmp/static_check && cd /tmp/static_check export PATH=/opt/qt-static/qt-5.9.9/bin:$PATH qmake static_check.pro make -j4如果构建顺利，make结束后目录里会出现一个static_check可执行文件。这一步说明 Qt 的.a归档库已经被链接器成功解析，没有出现“找不到 -lQt5Widgets”之类的错误。接下来做两个快速检查：
# 查看可执行文件的动态依赖，确认没有 libQt5*.so ldd ./static_check # 在带 X 显示的环境里跑一下，确认 xcb 插件能启动 ./static_checkldd的结果里如果只有libpthread、libX11、libxcb之类系统库，而没有任何libQt5Core.so.5、libQt5Widgets.so.5，说明 Qt 部分确实是静态链入的。窗口能弹出来，说明 xcb 平台插件也在静态阶段被正确处理了。这两关过了，才值得继续往下配置业务工程。
3. 构建环境与静态链接实操：qmake 参数、xcb 插件链法
3.1 构建机需要与 gcc485/libc217 保持同代
同样一段代码，在构建机编译出的二进制能不能在目标机跑，取决于构建机自身的发行版年代，而不是看交叉编译器版本。很多人拿到这套静态包后，随手在一台新系统上编译，编出来的文件虽然静态引用了 Qt，却动态依赖了新版 glibc 和 libstdc++，等于把静态包的保护全部抵消。
所以第一步先确认构建机的两个基础版本：
# 查看 glibc 版本 ldd --version | head -n 1 # 查看 gcc 版本 gcc --version | head -n 1判断标准很简单：构建机的 glibc 必须不高于目标机。包名写的是 libc217，最稳妥的做法就是找一台 glibc 2.17、gcc 4.8.5 的机器做构建。如果没有完全同代的机器，至少保证构建机 glibc 版本低于目标机，例如在 glibc 2.17 上编译，产物放到 glibc 2.31 的机器上没问题，反之就不是这套包能管的事了。
有些包内会自带一份定制 sysroot 或工具链，用来规避构建机版本不匹配。判断方法是看归档里有没有独立的gcc/、sysroot/目录。如果有，构建时就要把 PATH 和LD_LIBRARY_PATH都指到这套自带工具链上，避免系统编译器介入。我这里不假设包内一定带交叉工具链，只提示你优先检查这一层。
3.2 qmake 配置静态：CONFIG 里没有玄学，只有三个开关
静态链接不是把.so换成.a就完了。qmake 里真正生效的是三个配置点：
CONFIG += static：告诉 qmake 优先链接静态 Qt 库QMAKE_LFLAGS += -static-libgcc -static-libstdc++：把头两个系统运行库也静态化QMAKE_LFLAGS += -static：把所有依赖都静态化，但这条通常不推荐，因为会把 glibc 也链进去，导致运行时 DNS、用户数据库、locale 行为异常
实际写进.pro文件时，控制在下面这个范围：
# app.pro 的静态链接段 QT += core gui widgets network TARGET = myapp TEMPLATE = app CONFIG += release c++11 CONFIG += static # 静态链接 gcc 和 libstdc++，减少对目标机运行库的版本要求 QMAKE_LFLAGS += -static-libgcc -static-libstdc++ # 去掉 debug 段，避免把调试版 Qt 链进来 # release 已经放在上方 CONFIG 里 SOURCES += main.cpp networkworker.cpp这段配置里，CONFIG += static是 qmake 识别静态 Qt 的关键开关。构建静态 Qt 的库在编译时通常会把自己的.prl文件配置成只和.a交互，qmake 看到static后就去lib/找libQt5Widgets.a而不是.so。QMAKE_LFLAGS两个-static-lib*参数解决的是 C++ 运行时问题，这是新手最容易漏的：Qt 库本身是.a，但main函数和模板实例化最终会从libstdc++拉符号，不加这两个参数，产物就会依赖新版本libstdc++.so.6。
注意不要轻易用QMAKE_LFLAGS += -static把一切都静态化。把 glibc 静态链入的程序，在某些受限系统上会出现 getaddrinfo 解析异常，还会失去 NSS 模块支持。静态 Qt 的目的不是制造一个完全零依赖的二进制，而是让“Qt 这层”不要求目标机装运行库，系统底层该依赖还是依赖。
3.3 xcb 平台插件怎么固定：Q_IMPORT_PLUGIN 与 QTPLUGIN 两种路线
xcb 插件是 Linux 桌面 Qt 的显示出口。Qt 程序启动时，通过plugins/platforms/libqxcb.so或者静态体系里的qxcb归档库，和 X Window 建立连接。动态构建时，插件是运行时从platforms/目录里找的；静态构建时，这个插件必须在链接期就进到可执行文件里，否则就会出现经典的could not find the Qt platform plugin "xcb"。
静态环境下，qmake 通常通过QTPLUGIN变量自动处理平台插件：
# 在 .pro 中显式声明 xcb 插件 QTPLUGIN += qxcb把这个变量加进去后，qmake 会查询 mkspecs 里记录的插件元数据，找到对应插件的归档库，并把它连接进最终可执行文件。QTPLUGIN是按插件名匹配的，qxcb对应plugins/platforms/下的 xcb 平台插件，不是platforminputcontexts里的小插件。
另一种更可控的路子是在源码里手动导入插件，适合 qmake 自动匹配失败的情况：
// main.cpp 开头，QApplication 实例化之前导入 xcb 插件 #include <QtPlugin> Q_IMPORT_PLUGIN(QXcbIntegrationPlugin)Q_IMPORT_PLUGIN会把插件的静态初始化函数和元数据直接绑到当前目标文件里，链接时不再经历“是否有 -lqxcb 找不到”的过程。配合.pro文件里指定插件搜索路径：
# 手动指定插件库路径 LIBS += -L$$[QT_INSTALL_PLUGINS]/platforms -lqxcb$$[QT_INSTALL_PLUGINS]是 qmake 内置变量，指向 Qt 安装时记录的插件目录。用-L把该目录加入搜索路径，-lqxcb要求链接器找libqxcb.a。这条链路的坑在于，如果包内插件目录里没有静态版的libqxcb.a，而是只有libqxcb.so，-lqxcb会优先生成动态依赖，反而让“静态”名存实亡。所以执行完这一步后，务必回到ldd验证一次。
4. 避坑记录：把这套静态包搬到生产线前的五个常见翻车点
4.1 xcb 插件黑匣子报错，应用起不来
现象：static_check编译通过，拷到目标机运行，终端只输出一行This application failed to start because it could not find or load the Qt platform plugin "xcb"，窗口不出现，退出码非零。
原因：静态 Qt 构建时，xcb 插件没有进入可执行文件。可能是在.pro里没写QTPLUGIN += qxcb，也可能是包内plugins/platforms/目录里根本没有静态版 xcb 插件库，而 qmake 又无法自动匹配。还有一种隐蔽情况：构建时选了-no-xcb的 Qt 库，插件缺失发生在编译期而非运行期。
解决：先强制打开 Qt 插件调试日志，确认加载路径到底卡在哪：
# 输出 xcb 插件查找过程到 stderr QT_DEBUG_PLUGINS=1 ./static_check 2>&1 | grep -i xcb如果日志显示在某个目录里找libqxcb.so但找不到，说明包里就没有对应的静态/动态插件。这时回到构建机检查：
ls -l /opt/qt-static/qt-5.9.9/plugins/platforms/看到libqxcb.a就用Q_IMPORT_PLUGIN方式手动导入；只看到libqxcb.so，说明你手上不是完整静态包，需要补回 platform 插件源码重新编一次。
4.2 编译机正常、生产机报 GLIBC 版本找不到
现象：在开发机编译运行都没问题，交付到生产机后第一次执行就报错，提示version 'GLIBC_2.27' not found或者GLIBCXX_3.4.22 not found。
原因：构建机的 glibc 或 libstdc++ 比目标机新，编译出来的可执行文件带上了目标机不认识的符号版本。这一步和 Qt 静态与否无关，是 C 运行库层面的边界。
解决：对照 2.2 节的方式，先检查可执行文件里引用的最高 glibc 版本：
# 查看最终产物的 glibc 符号要求 objdump -T ./static_check | grep -oE 'GLIBC_[0-9.]+' | sort -V | tail -n 3如果最高版本超过目标机 glibc，除了更换构建机没有更干净的解法。把代码拉到 glibc 2.17 的构建机上重编一遍，重新验证static_check可以运行。还有一种临时方案是用patchelf降低符号版本，但 glibc 符号版本号的压制很危险，常常引发隐藏崩溃，不建议在正式项目里当常规手段。
4.3 https 请求失败，证书和 OpenSSL 没链进静态库
现象：程序里用QNetworkAccessManager请求https://地址，返回错误，或者QSslSocket直接不可用，日志提示cannot call unresolved function SSL_CTX_new。
原因：静态 Qt 包在编译 Qt Network 时可能没有把 OpenSSL 编进来，也可能把 OpenSSL 编成了静态库但证书路径没有跟着部署。前者导致运行时ssl功能为空，后者导致证书链验证失败。
解决：先确认 Qt 是否编译了 SSL 模块：
// main.cpp 输出支持的运行时版本 #include <QSslSocket> qDebug() << QSslSocket::sslLibraryBuildVersionString();有输出说明库没编崩，接着检查部署机的证书路径。静态程序内部默认的 CA 路径往往指向构建机上的/etc/ssl/certs/ca-certificates.crt，目标机不一定有相同路径。常用做法是在启动脚本里显式指定：
# 部署脚本里指定证书文件 export SSL_CERT_FILE=/etc/ssl/certs/ca-bundle.crt ./myapp如果 Qt 库本身没链 OpenSSL，则要查包内有没有libcrypto.a、libssl.a。没有这两个归档，就只能在部署机上额外安装 OpenSSL 动态库，然后接受“Qt 静态但 OpenSSL 动态”的混合状态。这不算完美，但比让 https 全部失效强。
4.4 Qt 5.9.9 太旧，和较新 libxkbcommon 冲突
现象：目标机系统比较新，Qt 程序启动后出现QXcbConnection: XKB extension not available，键盘输入无效或窗口无法响应。有时还伴随Failed to load xkbcommon类日志。
原因：Qt 5.9.9 是较老一代 LTS，其 xcb 插件对 xkbcommon 的符号解析是按当时的 API 写的。新版 libxkbcommon 库如果做了符号版本升级或 ABI 调整，老静态插件运行时就会匹配不上。
解决：确认目标机上libxkbcommon.so.0和libxkbcommon-x11.so.0存在且版本不过新。常见做法是部署时附带一份和构建机同代的libxkbcommon*.so.0，放到应用的私有目录，然后通过LD_LIBRARY_PATH让程序优先加载这套旧库。这在“Qt 静态、xcb 相关系统库动态”的混布场景里是能接受的。注意不要把LD_LIBRARY_PATH写成全局修改，要写进应用自己的启动脚本里，避免影响目标机上其他 Qt 程序。
4.5 误把动态 Qt 库带进发布目录，形成“混合发布”
现象：发布包里既有myapp可执行文件，又有libQt5Core.so.5、libQt5Widgets.so.5；应用运行时通过LD_LIBRARY_PATH找到了这些动态库，一切看似正常。等到目标机升级系统或换了一台 Linux 后，程序开始段错误，或者报Qt: symbol not found。
原因：开发环境里环境变量让动态库路径抢先于静态链接生效。静态 Qt 的链接器并没有为这些.so保留符号表条目，但运行时LD_LIBRARY_PATH会让动态装载器把同名符号塞进进程里，和静态库内部符号互相覆盖。这种“表面上能跑”的状态在更换运行库版本时最容易爆掉。
解决：发布目录里不携带任何libQt5*文件，从启动脚本里删掉针对 Qt 的LD_LIBRARY_PATH设定。验证手段非常简单，参考第 5 章的env -i方式，在完全干净的环境变量里运行应用。凡是在干净环境里起不来、带环境变量就能跑的产物，都应该按“混布风险”处理，重新编译或重新整理依赖。
5. 发布前的十分钟自检：ldd、清空环境、xcb 日志一起上
发布不是把可执行文件 cp 到服务器就结束。我的习惯是每次打包交付前，都跑一遍能堵掉大多数低端问题的自检。整个过程十分钟以内，值得写进你的发布脚本。
第一步，把所有可能掩盖问题的环境变量清掉，直接运行：
# 清空环境变量的前提下启动，避免 LD_LIBRARY_PATH 干扰 env -i ./myapp --help如果这条命令能正常输出，程序启动阶段才算安全。这里的关键在env -i，它不带任何继承的LD_LIBRARY_PATH，Qt 只能依赖可执行文件本身携带的链接信息，伪造静态产物会当场露馅。
第二步，检查动态依赖里有没有缺失：
# 找 not found 条目 ldd ./myapp | grep "not found" # 列出所有动态依赖，按路径排序，确认没有 Qt 库 ldd ./myapp | awk '{print $1}' | grep -E '^libQt'ldd输出里只要出现not found，说明机器上缺运行时依赖，需要确认是否在部署清单里。输出里出现任何libQt5*.so，说明静态链没有完全生效，要回编译环境里检查CONFIG += static和QTPLUGIN。
第三步，针对 GUI 应用，专门验证 xcb 插件加载：
# 打开插件装载日志，过滤 xcb 相关的成功/失败消息 QT_DEBUG_PLUGINS=1 ./myapp 2>&1 | grep -i "xcb" | head -n 20日志里出现类似QFactoryLoader::QFactoryLoader() checking directory path和loaded library "xcb"字样，说明平台插件阶段正常；如果停在某个.so或.a文件路径上报错，立刻回到第 4.1 节的排查路线。
最后一条经验送给容易被静态包“看起来绿了”迷惑的人：我从那以后每次发布都把这三条命令编成同一个 shell 脚本，跑完才算完成，不做任何跳过；即使第一次没问题，也会在换目标机、换系统补丁后重跑一遍，防的就是 Qt 静态库和系统运行库之间的隐性摩擦。希望帮到你。
本文还有配套的精品资源，点击获取
