PAYATHON 2026

QGC v5.0.8 在 Windows 10 上使用 Qt Creator 构建时卡住，如何排查？

数据阿明

结论

现有信息不足以确定根因。Qt Creator 停止更新进度，ninja.exe、cl.exe、cmake.exe 显示 0% CPU，这些现象都不能单独证明构建已经死锁。需要先找出当前正在执行或等待的具体命令，再决定如何排查编译、链接、依赖下载或构建环境问题。

原始材料没有提供该版本所需环境的具体要求，也没有给出失败日志，因此不能仅凭这些现象认定 Qt 6.8.3 与 QGroundControl v5.0.8 不兼容。

1. 在实际构建目录中获取详细输出

先停止 Qt Creator 中的构建，避免两个构建任务同时操作同一个目录。然后打开 Visual Studio 2022 x64 Developer Command Prompt，进入 Qt Creator 配置的构建目录。

该目录应包含 CMakeCache.txt 和 build.ninja。cmake --build . 中的 . 指当前构建目录。

运行：

cmake --build . --target all -j1 -v

你已经尝试过这条命令，下一步应保留停止输出时的完整命令和前后日志。-j1 将构建并行度限制为 1，便于对应当前任务；-v 用于显示详细构建命令。

如果需要保存输出，可以单独重试一次：

cmake --build . --target all -j1 -v > build-debug.log 2>&1

这条命令会把输出写入文件，终端不再持续显示日志。日志暂时不增长也不能直接说明挂起，某些工具运行期间本来就不会输出进度。

如果命令返回，再执行：

echo %ERRORLEVEL%

记录退出码。非零退出码说明构建已经失败，应优先分析日志中的错误。如果命令始终没有返回，则继续检查进程状态。

2. 确认具体是哪个子进程在等待

Ninja 负责调度任务，等待子进程时自身 CPU 占用率很低是正常现象。排查时，应结合任务管理器中的命令行、父子进程关系，以及一段时间内的 CPU、磁盘和网络活动来判断。

重点查看以下情况：

  • 正在编译或链接：检查实际运行的 cl.exe、link.exe 或其他构建工具，观察资源使用是否持续变化。单次 0% CPU 读数不足以判断异常。
  • 正在生成资源或代码：检查 Qt 工具、脚本或其他生成程序，记录其完整命令行和正在处理的文件。
  • 出现下载或外部依赖任务：日志或子进程显示此类操作时，再检查网络、代理和下载目标。
  • 出现交互窗口或错误对话框：检查是否有提示被其他窗口遮挡，导致构建进程一直等待操作。

详细日志中最后打印的命令是定位线索，但仍需与正在运行的进程核对。父进程可能还在等待它启动的其他程序。

3. 核对终端与 Qt Creator 使用的工具链

在用于重现问题的终端中运行：

where cmake
where ninja
where cl
cmake --version
ninja --version

把结果与 Qt Creator 的 Kit 配置核对，尤其要检查 CMake、Ninja、编译器路径和构建目录。Visual Studio Developer Command Prompt 提供了 MSVC 环境，但终端中的 CMake 和 Ninja 仍可能与 Qt Creator 使用的程序不同。

如果终端找不到某个程序，应先补齐该终端的环境配置，不能因此认定 Qt Creator 中的 Kit 也存在同样的问题。

在源码目录中，还可以记录当前检出状态：

git describe --tags --exact-match
git status --short
git submodule status --recursive

这些信息用于确认版本、工作区改动和 submodules 状态，不能单独证明依赖完整或版本组合兼容。此前即使执行过依赖安装脚本，也仍需结合脚本执行结果和当前日志，判断是否安装成功。

4. 使用新的构建目录排除旧缓存影响

如果当前构建目录曾切换过 Qt、编译器、源码版本或 Kit，可以在 Qt Creator 中指定一个新的构建目录，使用同一个 MSVC 2022 64-bit Kit 重新配置并构建。

保留原目录及日志，便于比较：

  • 新目录能够完成构建：优先检查原目录中的缓存、旧路径或生成文件。
  • 新目录仍停在同一条命令：围绕该命令及其子进程继续排查，重复清理缓存通常提供不了更多线索。
  • 仅在 Qt Creator 中出现问题：比较它与终端的构建参数、环境变量和工具路径。

不要同时改变 Qt 版本、编译器、构建模式和并行度，否则即使构建恢复，也难以判断是哪项变化起了作用。

进一步定位需要哪些信息？

目前需要收集停滞时的详细证据：完整构建命令、日志末尾几十行、当前活动子进程及其命令行、停滞持续时间，以及终端构建是否也停在同一个任务。

拿到这些信息后，才能判断应修复依赖、调整环境，还是调查某个编译或链接步骤。现阶段没有足够依据给出确定的参数修改或版本降级方案。

备注：内容仅供参考。