简介：Qt Creator 4.11.2 官方源代码包以 tar.gz 形式分发，面向需要在龙芯平台编译 Qt 开发环境、进行软件移植与适配的工程师和嵌入式开发者。软件包提供完整的 IDE 源代码，既能支撑二次开发，也可帮助理解编辑器、调试器、项目管理等核心模块的实现，解决跨架构编译中的依赖与适配问题。包内共 2000 个文件，主体为 995 个 C++ 头文件与 900 个 C++ 源文件，另含构建脚本、Markdown/txt 文档及少量辅助文件，压缩后大小约 33.57MB，目录结构清晰，便于按模块检索。目前已有 208 人学习/下载。版本号 4.11.2 属于成熟迭代，配套构建脚本可辅助梳理依赖关系，针对龙芯架构调整 qmake/cmake 参数，避免常见的交叉编译陷阱。就内容完整度而言，这份压缩包既适合作为从源码构建 IDE 的参考资料，也可为研究 Qt Creator 插件机制、界面框架和调试功能提供直接的工程素材，对希望深入理解 Qt 工具链的开发者具有较高实用价值。 刚接到一个离线环境下的C++ IDE构建任务，拿到手的源码包文件名就写着qt-creator-opensource-src-4.11.2.tar.gz。可能很多人第一反应是：Qt Creator 不是可以直接在官网下载安装包吗，为什么要折腾源码编译？但当你所在的开发环境与互联网物理隔离，或者需要为特定系统定制 Qt Creator 时，这个 tar.gz 源码包就是唯一的选择。这篇文章我就把从解压、配置、编译到排错的全过程记录下来，重点分享tar.gz解压命令和编译中容易踩的坑，给同样需要离线构建 Qt Creator 4.11.2 的朋友做一个参考。
1. 拿到源码包先搞懂这仨信息点
1.1 文件名拆解：qt-creator、4.11.2、tar.gz 分别是什么
先把这个长文件名拆开看，名字本身就透露了不少信息。qt-creator是 Qt 官方推出的跨平台集成开发环境，主要用于 C++ 和 Qt 项目的开发调试；opensource-src表示这是开源版本的源码包，而不是已经编译好的二进制安装包；4.11.2是版本号，属于 Qt Creator 4.x 系列的一个补丁版本，发布于 2019 年之后，稳定性和对 CMake 的支持都很有代表性；最后的tar.gz是归档压缩格式，相当于把一堆源码目录先用 tar 打包，再用 gzip 压缩，在 Linux 和 macOS 上非常常见。
很多新手会问：为什么不是.zip？因为 Qt 官方在持续集成环境中大量使用 Unix 工具链，tar.gz能够完整保留文件权限、符号链接和所有者的属性，这对于需要执行编译脚本的源码树来说至关重要。如果你在 Windows 上拿到这个文件，也不需要慌，用 7-Zip 或者 WinRAR 都能解开，只是解压之后的换行符和权限偶尔会有小问题，我后面会讲到。
1.2 为什么选择开源版源码包而非预编译安装包
不直接下载官方二进制安装包，最深的原因通常是目标平台与官方构建环境不同。比如你的目标机器是精简过的嵌入式 Linux，缺少标准桌面库，或者系统是国产化环境里的特殊 CPU 架构，这时官方提供的 x86_64 安装包根本跑不起来，源码编译几乎是唯一路径。
另外源码包还有一个好处：你可以修改 Qt Creator 的插件源码，增加自定义功能。4.11.2 这个版本整体采用 C++ 编写，插件机制非常清晰，如果你要做深度定制，比如集成公司内部的代码规范检查工具，或者替换默认的欢迎页面，都必须从源码出发。开源版源码包在 License 上也很友好，LGPL 授权允许动态链接方式使用，适合不少企业内部工具链的二次开发场景。
1.3 源码包体积和内容预览
qt-creator-opensource-src-4.11.2.tar.gz解压之后的体积不小，压缩包本身大约 20MB 左右，解压后源码目录大概 130MB。里面除了核心的 src 目录，还包括了很多示例插件、测试用例和文档。我在拿到包之后的第一件事不是急着解压，而是先检查文件的校验值，避免在传输过程中文件损坏，这个习惯也建议大家保留。
2. 从零开始解压源码包
2.1 tar.gz 解压命令：Linux 和 Windows 两个场景
在 Linux 或 macOS 终端里，tar.gz解压命令的标准写法是：
tar -zxvf qt-creator-opensource-src-4.11.2.tar.gz拆开来看，-z表示通过 gzip 解压缩，-x表示解包，-v是显示解压过程，-f指定文件名。如果希望解压时不输出文件列表，可以去掉-v；如果你需要解压到指定目录，可以加上-C参数：
tar -zxvf qt-creator-opensource-src-4.11.2.tar.gz -C /opt/需要注意的是，很多新同学容易把参数顺序搞错，-f后面必须紧跟压缩包文件名，不能写成tar -zxfv这种。另外，如果源码包已经提前被 gzip 解压过变成了.tar文件，可以直接用tar -xvf解包，不过一般情况下我们拿到的就是.tar.gz格式。
在 Windows 环境下，如果你用的是 Git Bash 或者 WSL，同样可以使用上面的命令。如果只装了 7-Zip，可以先右键解压得到.tar文件，然后再解压一次，得到最终的源码目录。这里建议在 Windows 上优先选择 7-Zip 或 WSL，因为系统自带的资源管理器对 tar 包的长路径支持不好，遇到文件名过长会报错。
2.2 解压后目录结构速览
解压完成后，进入目录看一下：
cd qt-creator-opensource-src-4.11.2 ls -la你会看到类似下面的顶层结构：
src/：Qt Creator 的核心源码，包括 app、plugins、libs 三个子目录qmake/：项目管理文件，源码包采用 qmake 构建cmake/：CMake 辅助模块，部分测试和插件会用到doc/：文档源码tests/：自动化测试用例dist/：安装打包相关的配置脚本qtcreator_plugin_install.pri：插件安装规则文件
这里最有价值的是src/plugins，里面躺着所有内置插件，比如代码补全、Git 集成、调试器支持等。如果你要做二次开发，这里的代码是主要参考对象。还有share/qtcreator目录，存放了一些模板和默认配置，运行时会加载这些数据。
3. 编译安装前的环境和依赖准备
3.1 编译 Qt Creator 到底需要哪些“原材料”
Qt Creator 4.11.2 本身是 Qt 应用，所以必须先有 Qt 的开发库。官方要求最低 Qt 5.6，但实际建议用 Qt 5.12 或更高版本，因为 4.11.2 中的不少新特性依赖于 5.9 以上的接口。我在编译时用的是 Qt 5.12.10，整体比较顺利。
除了 Qt 库，还需要一套成熟的 C++ 编译器。Linux 上可以用 GCC 5.3 以上版本，Windows 上则推荐 MSVC 2015/2017。编译器版本过低会导致 C++14 标准的部分特性编译不过，报错往往很隐蔽。此外，构建过程中需要perl、python等脚本工具，CMake 版本建议在 3.1 以上，这是因为不少插件模块通过 CMake 检查依赖。
在 Debian/Ubuntu 系统上，可以提前安装系统依赖：
sudo apt-get install build-essential libgl1-mesa-dev libx11-dev libxkbcommon-dev libxcb-* libglib2.0-dev perl python3这里需要多说一句，e2fsprogs 这类基础系统包与 Qt Creator 没有直接依赖关系，不必因为网上有人提到就去特意装。它们只是 Linux 文件系统工具，容易和源码构建杂糅在一起讨论，其实并不影响 Qt Creator 的编译。
3.2 用 qmake 而不是 configure 的构建流程
Qt Creator 源码包的构建系统是 qmake，官方没有走 configure 脚本那套流程。所以你需要先确保qmake命令在 PATH 环境中。可以用：
qmake -v查看版本。如果你安装了多个 Qt 版本，最好把目标 Qt 的 qmake 路径传进环境变量：
export PATH=/opt/Qt5.12.10/5.12.10/gcc_64/bin:$PATH然后进入源码目录，执行：
mkdir build cd build qmake ../qt-creator-opensource-src-4.11.2/qtcreator.pro这里我专门创建了一个 build 目录来做影子构建，这样源码目录不会被生成物弄脏，方便以后重新构建。如果你不需要修改源码，影子构建是最推荐的方式，因为 Qt Creator 的构建产物有几百 MB，全部丢在源码目录里会干扰后续的 patch 管理。
接下来直接开编译：
make -j4-j4表示启用 4 个并行编译任务，如果机器内存充足可以提高到-j8，但不要超过 CPU 核心数太多，否则内存不足会导致编译器被 OOM kill。整个编译过程在 8 核 16GB 内存的机器上大约需要 15~25 分钟，如果是双核老机器，可以先去泡杯咖啡了。
4. 编译过程中的常见问题与排查实录
4.1 经典报错：找不到 Qt5Config.cmake / qmake 版本不对
编译到一半，最常见的第一类错误是：
CMake Error at cmake/Qt5CoreMacros.cmake:... Could not find a package configuration file provided by "Qt5Core"或者：
Project ERROR: Unknown module(s) in QT:Quick这两个报错本质都是 Qt 环境没有配置正确。如果是影子构建里没有执行 qmake 之前的 PATH 导出，系统会默认调用了一个旧版本的 qmake，导致生成的 Makefile 里 Qt 版本错乱。解决办法很简单：删除 build 目录，重新确认qmake -v输出的是你期望的版本，再重新 qmake 和 make。
我遇到的另个让人困惑的情况是 qmake 版本对，但依然报Unknown module(s)。这是因为你安装的 Qt 缺少对应的模块，比如 Qt Quick 模块没有安装。在编译 Qt Creator 的源码前，需要确认你的 Qt 安装包包含了qtquickcontrols2和qtdeclarative模块。如果只装了基础模块，解决方法是补装：
# 如果你的Qt来自在线安装器，重新运行安装器添加Qt Quick模块 # 如果是系统包，使用 apt-get install qtdeclarative5-dev对于离线环境，最稳妥的方式是提前把完整的 Qt 库目录一起拷贝过去，不要只拷几个模块目录。
4.2 GL/gl.h 缺失和链接失败的几个经典坑
在纯净的 Linux 服务器上编译 Qt Creator，很容易遇到：
fatal error: GL/gl.h: No such file or directory这个错误意味着缺少 OpenGL 开发头文件。Qt 的 GUI 模块依赖 OpenGL 库，即使是使用软件渲染也需要基础头文件。解决方法在 Debian/Ubuntu 上是安装：
sudo apt-get install build-essential libgl1-mesa-dev在安装完依赖后，重新运行 make 通常就能继续。这里有个小技巧：如果不想装整个 Mesa 库，也可以安装mesa-common-dev，但实际体验不如直接装libgl1-mesa-dev省心。
另一个容易栽的坑是最后链接时报一堆undefined reference to。这类问题多半是 Qt 库版本与编译器 ABI 不兼容。比如你拿着 GCC 9 的系统去链接用 GCC 5 编译的 Qt 库，就会因为 C++ 标准库版本不一致而报错。解决办法是让 Qt 库和 Qt Creator 源码使用同一套编译工具链。在离线环境下，最省事的方法是直接下载 Qt 官方预编译的 Linux 版本，它匹配官方支持的编译器范围，会比自己在目标机上源码编译一个 Qt 再编译 Qt Creator 快得多。
我把编译中经常遇到的问题整理成了速查表，方便直接对照：
| 报错信息 | 可能原因 | 解决思路 |
|---|---|---|
Qt5CoreConfig.cmake missing | qmake/CMake 环境路径不对 | 重新配置 PATH，删除 build 目录再试 |
Unknown module(s) in QT: Quick | Qt 缺少 Quick 模块 | 补装 qtdeclarative5-dev 或完整 Qt 模块 |
GL/gl.h: No such file or directory | 缺少 OpenGL 开发包 | apt-get install libgl1-mesa-dev |
Cannot find -lGL | OpenGL 链接库缺失 | 安装libgl-dev或libgl1-mesa-dev |
undefined reference to ... | ABI 不匹配，编译器版本混用 | 统一 Qt 库和编译器的工具链版本 |
virtual memory exhausted | 编译并行数过高导致 OOM | 降低-j数值，或增加 swap |
4.3 解压环节的文件权限问题
除了编译阶段，解压环节也会暗藏问题。有些情况下你会看到源码目录里的脚本没有执行权限，这是因为 tar.gz 中的文件是从 Windows 系统解压出来的，或者拷贝过程丢失了 Unix 权限位。遇到这种情况，可以在源码根目录统一修复可执行权限：
chmod +x configure在 Qt Creator 的构建流程中，大部分脚本是通过sh script.sh方式调用的，所以权限问题不算致命，但如果你自己写的扩展脚本用./xxx方式执行，就会遇到 Permission denied。此外，如果源码目录所在文件系统是 vfat 或 exfat，不支持符号链接，编译时可能解不开某些头文件链接，建议使用 ext4 或 xfs 文件系统存放源码。
5. 安装后的验证与 Kit 配置心得
5.1 启动第一次，配置 Qt Version 和 Compiler
编译成功后，直接在 build 目录下会生成可执行文件qtcreator，如果不做安装，也可以直接运行。但规范的做法是安装到系统目录：
make install默认安装路径是/usr/local/bin和/usr/local/lib，会安装一些共享资源文件。如果你的构建目录里有很多插件，install 之后检查一下插件目录是否完整，通常是：
/usr/local/lib/qtcreator/plugins如果启动时提示找不到插件，可以手动设置环境变量，让 Qt Creator 找到插件目录：
export QT_PLUGIN_PATH=/usr/local/lib/qtcreator/plugins首次启动 Qt Creator，它不会自动检测你的 Qt 套件，需要手动添加。步骤是：菜单 Tools -> Options -> Kits -> Qt Versions，选择你编译时使用的 qmake 路径；然后在 Compilers 页签添加对应的 GCC 编译器；最后在 Kits 页签里新建一个套件，把 Qt Version 和 Compiler 关联起来。保证调试器和 CMake 路径也配置正确后，一个可用的开发环境就算搭建完成了。
5.2 离线环境下的补充建议
在整个过程中我体会最深的一点是：离线构建不要迷信一条命令走到黑。Qt Creator 的构建系统虽然有成熟的一键流程，但系统环境的细微差异会引发各种诡异问题。如果可能，尽量在目标机器上先构建一个和源码版本匹配的 Qt 库，或者从官方二进制安装包中抽取库目录使用。另外，建议在联网环境提前下载好所有依赖包，保存到离线仓库里，比如 apt 的/var/cache/apt/archives或者用 pip download 缓存，避免构建到一半缺东西。
还有一点补充经验：qt-creator-opensource-src-4.11.2.tar.gz 的源码目录中内置了一些单元测试，构建时默认不会编译它们，不需要担心测试代码会拖慢构建速度。如果后续你想运行测试，需要手动添加-DQT_WITH_TESTS=ON这类参数，但普通使用完全没必要。
5.3 一个小技巧：用脚本快速打包构建产物
当你需要在多台离线机器上部署同一个 Qt Creator 时，不用每台机器都编译一遍。我通常在构建机完成后，把整个安装目录打包：
tar -zcvf qtcreator-4.11.2-custom.tar.gz /usr/local/bin/qtcreator /usr/local/lib/qtcreator然后把这个打包文件分发到目标机器上即可。相比源码编译，安装目录的依赖会少很多，只要目标机器的 Qt 库版本一致，通常可以直接运行。不过这样做的前提是你用静态链接方式处理了部分依赖，否则还是要保证目标机器有必要的 shared library。这个思路我们平时做内部工具分发时屡试不爽，省掉了大量重复编译时间。
本文还有配套的精品资源，点击获取
