Ubuntu源码编译CMake：版本可控与构建稳定性的工程实践

Ubuntu源码编译CMake：版本可控与构建稳定性的工程实践

发布时间：2026/10/19 11:23:55
Ubuntu源码编译CMake：版本可控与构建稳定性的工程实践 1. 项目概述为什么在 Ubuntu 上亲手编译 CMake 是一项值得投入时间的基础能力“ubuntu 编译 cmake”这六个字看似简单实则直击 Linux 开发环境构建中最常被低估、却最影响长期稳定性的关键环节。我带过不少刚从 Windows 或 macOS 转来的开发者他们第一次在 Ubuntu 上跑 C 项目时往往卡在CMakeLists.txt报错“CMake version too old”或者find_package(Threads REQUIRED)失败——查了半天发现系统自带的cmake是 3.10.2而项目要求最低 3.16再一查apt install cmake装完还是 3.10.2。这不是个别现象而是 Ubuntu LTS 版本策略带来的必然结果它优先保障系统级软件包的稳定性与兼容性而非开发工具链的前沿性。于是你面对的不是“要不要编译”而是“迟早要编译”——只是时间早晚的问题。这个动作背后解决的远不止一个版本号问题。它实际承载着三层核心需求第一层是版本可控性——你能精确锁定某次 CI 构建所用的 CMake 版本比如 3.22.6避免因系统升级导致构建行为突变第二层是功能完整性——官方二进制包默认关闭部分高级特性如 Ninja Multi-Config 支持、CUDA 12.2 的完整检测逻辑而源码编译可全量启用第三层是调试与定制能力——当遇到cmake -G Ninja生成器异常、或FetchContent_Declare在特定网络环境下超时失败时你能直接加-DCMAKE_BUILD_TYPEDebug编译带符号表的版本用gdb进入cmake自身源码逐行追踪。这些能力在你接手一个跨团队协作的大型 C 项目、或维护一个需长期支持多个 Ubuntu 版本的嵌入式 SDK 时会成为决定交付周期的关键变量。适合谁来认真读完这篇如果你是以下任一角色这篇文章就是为你写的正在搭建 CI/CD 流水线的 DevOps 工程师需要确保所有构建节点 CMake 行为一致从事机器人、自动驾驶等领域的 C 开发者依赖 PCL、ROS2 等对 CMake 版本敏感的生态高校实验室里维护老旧服务器Ubuntu 18.04的研究员无法随意升级系统但必须跑新算法或是刚考完 LPIC-1、正尝试把书本知识落地到真实开发流中的 Linux 新手。它不假设你熟悉 Autotools也不要求你写过 CMake 模块但会带你从./configure的本质讲起让你明白为什么make install后/usr/local/bin/cmake会覆盖系统路径以及如何用update-alternatives安全地管理多版本共存。这不是一次性的“安装教程”而是一套可沉淀、可复用、可写进团队 Wiki 的环境治理方法论。2. 整体设计思路与方案选型为什么坚持源码编译而不是 snap、pip 或第三方 PPA在 Ubuntu 上获取新版 CMake表面看有至少五种路径apt install cmake系统源、snap install cmake --classicSnap 包、pip install cmakePython wheel、添加https://apt.kitware.com/PPA 后apt install cmake以及本文聚焦的源码编译。我曾在一个持续集成集群上同时测试过这五种方式耗时 3 周最终全部弃用前四种只保留源码编译作为唯一标准流程。原因不是偏执而是每种方案在真实生产场景中都暴露出不可忽视的硬伤而这些伤痕往往在项目上线前三天才浮现。先说apt install。Ubuntu 20.04 LTS 默认提供 CMake 3.16.322.04 是 3.22.1看似够用。但问题在于“够用”的定义权不在你手上。某次我们为 ROS2 Humble 升级其colcon工具链明确要求 CMake ≥3.24.0而 Ubuntu 22.04 的官方源直到 22.04.3 才更新到 3.24.2——这意味着你得等半年系统更新或手动下载.deb包强行安装后者极易引发libcurl4与libssl1.1的依赖冲突。更隐蔽的风险是 ABI 兼容性系统源的 CMake 是用 GCC 11 编译的而你的项目用 GCC 12 构建某些自定义 FindXXX.cmake 模块在解析target_link_libraries时会出现符号解析错误这种 bug 极难复现日志里只显示CMake Error at CMakeLists.txt:42 (add_library):没有具体原因。Snap 方案看起来干净隔离--classic模式也绕过了 strict confinement。但实测发现它在 Docker 容器内运行时cmake .. -G Unix Makefiles会静默失败因为 Snap 的 mount namespace 机制与容器的overlayfs存在竞态生成的Makefile缺少关键的CMAKE_COMMAND变量定义。我们曾因此导致整个 CI 流水线卡在“Build Stage”排查了 17 小时才定位到 Snap 的--devmode参数缺失。而pip install cmake更是陷阱重重它安装的是scikit-build-core封装的 CMake 二进制但该包在 ARM64 架构如树莓派 5上默认下载 x86_64 镜像报错cannot execute binary file: Exec format error且其cmake命令实际是 Python 脚本包装器调用subprocess.run()启动真正的二进制这在高并发构建如make -j16时会因 Python GIL 锁导致 CPU 利用率骤降 40%。PPA 方案看似折中Kitware 官方维护的apt.kitware.com确实提供各版本 CMake。但它的更新节奏与 Ubuntu 发行版绑定当你在 Ubuntu 20.04 上apt update apt install cmake得到的是针对 20.04 编译的二进制它链接的是libstdc.so.6.0.28而你的项目若使用较新的 GCC如 GCC 13其libstdc.so.6.0.30与之不兼容cmake启动即报symbol lookup error。我们曾因此在客户现场演示时cmake --version正常但一执行cmake ..就崩溃尴尬至极。最终选择源码编译核心逻辑就三点可控、透明、可审计。可控指你能指定任意 commit hash如v3.28.1tag确保所有节点构建完全一致透明指编译过程全程可见CMakeCache.txt里每个选项CMAKE_BUILD_TYPE、CMAKE_INSTALL_PREFIX都由你亲手确认可审计指生成的二进制可被readelf -d /usr/local/bin/cmake | grep NEEDED检查依赖库strings /usr/local/bin/cmake | grep kitware验证来源。更重要的是它天然规避了所有包管理器的“黑盒”特性——你不需要信任某个 PPA 维护者的签名密钥是否过期也不用担心 Snap store 的 CDN 是否被劫持。在金融、航天等对供应链安全有强要求的领域这是合规审计的硬性门槛。所以这不是“技术洁癖”而是工程成熟度的分水岭当你的项目从“能跑通”迈向“可交付”源码编译 CMake 就不再是可选项而是必经之路。3. 核心细节解析与实操要点从依赖准备到安装路径的每一个决策依据在 Ubuntu 上编译 CMake表面看只有三步git clone、./configure实际是cmake自举、make make install。但每一步背后都有至少三个需要你主动决策的细节而这些细节的选择直接决定了后续三个月的开发体验是顺畅还是痛苦。我以 Ubuntu 22.04 为基准环境结合过去三年在五个不同项目中的踩坑记录把每个关键点拆解到原子级别。3.1 依赖安装为什么build-essential不够必须显式安装libssl-dev和libcurl4-openssl-dev很多教程只写sudo apt install build-essential这在旧版 CMake3.20中或许可行但从 3.20 开始CMake 的FetchContent和ExternalProject_Add模块深度依赖 HTTPS 下载能力而其底层是libcurl。build-essential只包含gcc、g、make、dpkg-dev不包含任何网络库。如果你跳过这步执行cmake .时会报错CMake Error at Utilities/cmlibcurl/CMakeLists.txt:123 (message): libcurl not found. Please install libcurl development package.但问题没这么简单。libcurl4-openssl-dev和libcurl4-gnutls-dev都能提供libcurl选哪个答案是openssl。因为 Kitware 官方构建脚本见CMake/Source/Utilities/cmlibcurl/CMakeLists.txt默认启用CURL_USE_OPENSSL若你装了gnutls版本编译会卡在cmlibcurl模块报OPENSSL_INCLUDE_DIR-NOTFOUND。更隐蔽的是libssl-dev它看似是libcurl4-openssl-dev的依赖但某些最小化安装的 Ubuntu如ubuntu-server-cloudimg-amd64中libcurl4-openssl-dev的依赖关系可能被破坏apt不会自动拉取libssl-dev。此时cmake编译到cmcurl阶段会提示openssl/ssl.h: No such file or directory。我的做法是显式安装三者sudo apt update sudo apt install -y build-essential libssl-dev libcurl4-openssl-dev zlib1g-dev其中zlib1g-dev是为了支持cmake自身的压缩功能如cmake -E tar解压.tar.gz虽非强制但省去后续报错重装的麻烦。3.2 源码获取为什么不用 GitHub Release ZIP而坚持git clone --depth 1 --branch v3.28.1Kitware 在 GitHub Releases 页面提供cmake-3.28.1.tar.gz解压后大小约 12MB比git clone快得多。但我在两个项目中因此翻车第一次是某医疗设备 SDK要求 CMake 3.28.1 的某个 commit 修复了CUDA_ARCHITECTURES在 Clang 16 下的解析 bug而 Release ZIP 对应的是v3.28.1tag那个 fix 在v3.28.1-rc3后才合入第二次是某军工项目审计要求所有源码必须可追溯到 Git commit hashZIP 包无法提供git log信息。git clone --depth 1仅下载最新 commit体积与 ZIP 相当约 15MB却保留了完整的 Git 元数据。命令如下git clone --depth 1 --branch v3.28.1 https://gitlab.kitware.com/cmake/cmake.git cd cmake注意Kitware 已将主仓库从 GitHub 迁移至 GitLabgitlab.kitware.com用旧地址会 404。--branch参数必须指定确切 tag不能写master或main否则下次git pull可能拉到不稳定代码。3.3 构建目录与安装路径为什么mkdir build cd build是铁律且CMAKE_INSTALL_PREFIX必须设为/usr/localCMake 的构建系统是“源码分离”的即构建文件.o、Makefile不能和源码混在一起。mkdir build cd build不是仪式感而是避免污染源码树。若你在源码根目录直接cmake .会生成CMakeCache.txt、CMakeFiles/等数十个文件git status全红git clean -fdx又怕误删重要文件。更严重的是并行构建风险当你make -j4时多个子进程可能同时写CMakeCache.txt导致缓存损坏cmake ..报Parse error in cache file。CMAKE_INSTALL_PREFIX的设定更是关键。默认值是/usr/local这符合 Linux Filesystem Hierarchy StandardFHS规范/usr下存放系统包管理器安装的软件/usr/local下存放本地编译安装的软件。若你改成/opt/cmake或/home/user/cmake会引发连锁反应首先cmake二进制启动时会从CMAKE_INSTALL_PREFIX/share/cmake-3.28/Modules/加载标准模块如FindBoost.cmake路径硬编码在二进制中其次其他工具如ccmake、cmake-gui的图标、翻译文件也按此路径查找最后update-alternatives管理多版本时/usr/local/bin是标准候选路径。我曾见过有人设为/tmp/cmake结果cmake --help显示No modules found因为/tmp/cmake/share/...权限被tmpfs的noexec标志阻止。3.4 编译参数为什么cmake -DCMAKE_BUILD_TYPERelease -DCMAKE_INSTALL_PREFIX/usr/local ..中Release不可省略CMAKE_BUILD_TYPE决定编译器优化级别。Release对应-O3 -DNDEBUGDebug对应-g -O0。新手常以为“反正只是编译工具Debug 也没事”。错。CMake 本身是个复杂程序其cmake二进制大小约 12MBRelease vs 85MBDebug加载速度差 3 倍。更重要的是Debug版本会开启大量断言assert()在处理超大CMakeLists.txt如 Chromium 的 5000 行时频繁的断言检查会让配置阶段cmake ..耗时从 8 秒飙升至 42 秒。而Release版本经过充分测试稳定性反而更高。Kitware 官方发布的二进制也是Release构建的保持一致是减少未知问题的前提。提示不要加-D CMAKE_CXX_STANDARD17等参数。CMake 的构建系统自身用 C11 编写这些参数对它无效只会污染CMakeCache.txt增加维护成本。4. 实操过程与核心环节实现从零开始的完整编译流水线与参数验证现在我们进入真正动手的环节。以下步骤已在 Ubuntu 22.04Linux 5.15.0-105-generic上实测通过全程无sudo以外的权限需求所有命令均可复制粘贴执行。我会在每个关键步骤后解释其作用、可能的输出、以及如何验证是否成功而不是简单罗列命令。4.1 环境初始化与依赖安装打开终端执行# 更新包索引确保获取最新依赖信息 sudo apt update # 安装编译所需的核心工具链和库 # build-essential: gcc, g, make, dpkg-dev # libssl-dev: OpenSSL 头文件用于 HTTPS 支持 # libcurl4-openssl-dev: libcurl 开发包FetchContent 依赖 # zlib1g-dev: zlib 压缩库用于 cmake -E tar 等功能 sudo apt install -y build-essential libssl-dev libcurl4-openssl-dev zlib1g-dev # 验证基础工具是否存在且版本合理 gcc --version # 应输出 gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 或更高 make --version # 应输出 GNU Make 4.3 或更高这一步耗时约 2-3 分钟取决于网络速度。apt install结束后libcurl的头文件应位于/usr/include/curl/可通过ls /usr/include/curl/curl.h确认。若报No such file or directory说明libcurl4-openssl-dev未正确安装需重试。4.2 源码获取与构建目录创建# 创建工作目录建议放在 /tmp 或 ~/src避免权限问题 mkdir -p ~/src cd ~/src # 克隆 CMake 源码指定确切版本 v3.28.1 # 注意使用 gitlab.kitware.com 地址非 github.com git clone --depth 1 --branch v3.28.1 https://gitlab.kitware.com/cmake/cmake.git # 进入源码目录 cd cmake # 创建独立的构建目录与源码分离 mkdir build cd buildgit clone成功后ls -l应看到CMakeLists.txt、Source/、Tests/等目录。cd build后pwd输出应为~/src/cmake/build。此时ls应为空证明构建目录干净。4.3 CMake 自举配置理解cmake ..的双重身份这是最易混淆的环节。当前你在build/目录下执行cmake ..这里的cmake命令是谁是系统自带的旧版 CMake如 3.22.1。它负责读取源码根目录..下的CMakeLists.txt生成build/下的Makefile。这个过程叫“自举”bootstrapping即用旧 CMake 构建新 CMake。# 执行自举配置指定安装路径和构建类型 cmake -DCMAKE_BUILD_TYPERelease -DCMAKE_INSTALL_PREFIX/usr/local .. # 验证配置是否成功检查关键变量 grep CMAKE_INSTALL_PREFIX CMakeCache.txt # 应输出CMAKE_INSTALL_PREFIX:PATH/usr/local grep CMAKE_BUILD_TYPE CMakeCache.txt # 应输出CMAKE_BUILD_TYPE:STRINGReleasecmake ..执行时间约 1-2 分钟。成功后CMakeCache.txt会生成其中CMAKE_INSTALL_PREFIX必须是你指定的/usr/local。若显示/usr/local说明配置成功若显示/usr或其他路径说明参数未生效需检查命令拼写-D后无空格CMAKE_INSTALL_PREFIX后无空格。4.4 编译与安装make的并行策略与sudo make install的权限逻辑# 使用 4 个线程编译平衡速度与系统负载 # 若 CPU 核心数多于 4可用 -j$(nproc)但笔记本建议 -j4 避免过热 make -j4 # 编译成功后验证生成的二进制 ./bin/cmake --version # 应输出cmake version 3.28.1 # 安装到 /usr/local/bin/ sudo make install # 验证安装是否覆盖系统路径 which cmake # 应输出/usr/local/bin/cmake cmake --version # 应输出cmake version 3.28.1不再是旧版本make -j4是关键提速点。make默认单线程编译 CMake约 200 个源文件需 15-20 分钟-j4可压缩至 4-5 分钟。但-j值并非越大越好-j16在 8 核 CPU 上会导致内存爆满cc1plus进程占用 2GB RAMmake报virtual memory exhausted。-j4是 Ubuntu 22.04 桌面版16GB RAM的黄金值。sudo make install的本质是cp操作将build/bin/cmake复制到/usr/local/bin/cmakebuild/share/cmake-3.28/复制到/usr/local/share/cmake-3.28/。which cmake返回/usr/local/bin/cmake证明$PATH中/usr/local/bin在/usr/bin之前Ubuntu 默认如此新版本已生效。4.5 多版本共存管理update-alternatives的安全切换方案编译安装后旧版 CMake/usr/bin/cmake并未删除仍可访问。为避免混乱用update-alternatives统一管理# 将新旧版本注册到 alternatives 系统 sudo update-alternatives --install /usr/bin/cmake cmake /usr/bin/cmake 10 sudo update-alternatives --install /usr/bin/cmake cmake /usr/local/bin/cmake 20 # 查看当前配置 sudo update-alternatives --config cmake # 会列出两个选项编号 0 和 1输入编号选择 # 验证切换效果 cmake --version--install命令中10和20是优先级priority数值越大越优先。/usr/local/bin/cmake设为 20意味着update-alternatives --auto cmake会自动选它。--config是交互式切换适合临时回退。此方案比直接rm /usr/bin/cmake安全百倍因为apt upgrade时/usr/bin/cmake会被重新安装而update-alternatives记录依然有效。4.6 功能验证不只是--version还要测真实构建能力版本号正确只是第一步。必须验证 CMake 的核心功能是否正常# 创建一个最小测试项目 mkdir -p ~/test-cmake cd ~/test-cmake cat CMakeLists.txt EOF cmake_minimum_required(VERSION 3.10) project(TestCMake LANGUAGES CXX) add_executable(hello main.cpp) target_compile_features(hello PRIVATE cxx_std_17) EOF cat main.cpp EOF #include iostream int main() { std::cout Hello from CMake __VERSION__ !\n; return 0; } EOF # 执行配置和构建 cmake -B build -S . -G Unix Makefiles cmake --build build # 运行测试二进制 ./build/hello # 应输出Hello from CMake ...!此测试覆盖了cmake_minimum_required、add_executable、target_compile_featuresC17 特性、-G Unix Makefiles生成器、--build构建命令五大核心功能。若cmake -B build报错Unknown CMake command target_compile_features说明 CMake 版本未生效若cmake --build build报No rule to make target all说明Makefile生成失败需检查CMakeLists.txt语法。5. 常见问题与排查技巧实录来自真实项目的 7 个高频故障与根因分析在超过 200 台 Ubuntu 开发机和 CI 节点上部署 CMake 编译流程后我整理出以下 7 个最高频、最棘手的问题。每个问题都附有现场日志片段、根本原因、三步排查法和永久解决方案。它们不是教科书式的“可能遇到”而是你明天就会撞上的真实障碍。5.1 问题cmake ..报错Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the system variable OPENSSL_ROOT_DIR现场日志CMake Error at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Could NOT find OpenSSL (missing: OPENSSL_CRYPTO_LIBRARY OPENSSL_SSL_LIBRARY) Call Stack (most recent call first): /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake-3.22/Modules/FindOpenSSL.cmake:470 (find_package_handle_standard_args) Utilities/cmlibcurl/CMakeLists.txt:115 (find_package)根因分析这不是 OpenSSL 未安装而是 CMake 的FindOpenSSL.cmake模块在搜索路径时忽略了/usr/lib/x86_64-linux-gnu/这个 Ubuntu 特有的库路径。libssl-dev安装的libssl.so实际在/usr/lib/x86_64-linux-gnu/libssl.so而旧版FindOpenSSL.cmake3.22 及以前只查/usr/lib和/usr/local/lib。三步排查法ls /usr/lib/x86_64-linux-gnu/libssl*—— 确认库文件存在pkg-config --modversion openssl—— 输出3.0.2证明 pkg-config 可识别echo $OPENSSL_ROOT_DIR—— 为空证明环境变量未设置。永久解决方案在cmake ..命令中显式指定路径cmake -DCMAKE_BUILD_TYPERelease \ -DCMAKE_INSTALL_PREFIX/usr/local \ -DOPENSSL_ROOT_DIR/usr/lib/x86_64-linux-gnu \ ..此参数告诉FindOpenSSL.cmake优先在此目录下搜索一劳永逸。Kitware 在 3.24 版本中已修复此路径问题但若你必须用 3.22此参数是刚需。5.2 问题make -j4中途报错cc1plus: out of memory allocating 65536 bytes after a total of 2147483648 bytes现场日志g: fatal error: Killed signal terminated program cc1plus compilation terminated. make[2]: *** [Source/cmCommandArgumentParserHelper.cxx.o] Error 1根因分析cc1plus是 GCC 的 C 前端此错误表明系统内存不足。Ubuntu 22.04 默认 swap 空间为 2GB而 CMake 编译峰值内存占用可达 3.5GB尤其在cmCore模块链接阶段。-j4启动 4 个cc1plus进程每个峰值 1GB瞬间耗尽内存。三步排查法free -h—— 查看Mem:和Swap:行若Swap:为0B或2G即为根因dmesg | tail -20 | grep -i killed process—— 若输出Killed process 12345 (cc1plus)证实 OOM Killer 干预ulimit -v—— 输出unlimited排除用户级内存限制。永久解决方案创建 4GB swap 文件sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile # 永久生效echo /swapfile none swap sw 0 0 | sudo tee -a /etc/fstab此后make -j4稳定运行。此操作在云服务器如 AWS EC2 t3.medium上尤为必要。5.3 问题cmake --version显示 3.28.1但cmake .. -G Ninja报错Generator Ninja is not supported现场日志CMake Error: Could not create named generator Ninja Generators * Unix Makefiles Generates standard UNIX makefiles. Green Hills MULTI Generates Green Hills MULTI files.根因分析CMake 源码编译时默认不启用 Ninja 生成器除非检测到ninja-build已安装。ninja-build是独立工具apt install ninja-build即可但很多教程遗漏此步。cmake二进制在编译时会检查ninja --version若不存在则不编译 Ninja 支持代码。三步排查法ninja --version—— 若报command not found即为根因cmake --help | grep -A5 Generators—— 输出中无Ninja证实未启用ldd /usr/local/bin/cmake | grep ninja—— 空输出证明未链接 Ninja 库。永久解决方案sudo apt install -y ninja-build # 重新编译 CMake无需重装依赖 cd ~/src/cmake/build make clean cmake -DCMAKE_BUILD_TYPERelease -DCMAKE_INSTALL_PREFIX/usr/local .. make -j4 sudo make installmake clean清除旧构建缓存cmake ..会重新检测ninja并启用支持。此后cmake -G Ninja正常。5.4 问题sudo make install后ccmake图形界面无法启动报错ccmake: error while loading shared libraries: libncursesw.so.6: cannot open shared object file现场日志/usr/local/bin/ccmake: error while loading shared libraries: libncursesw.so.6: cannot open shared object file: No such file or directory根因分析ccmake依赖libncursesw宽字符版 ncurses但 Ubuntu 22.04 的libncursesw6包名是libncursesw6其.so文件名为libncursesw.so.6.3而ccmake编译时链接的是libncursesw.so.6符号链接。apt install libncursesw6后/usr/lib/x86_64-linux-gnu/libncursesw.so.6应存在但某些最小化安装镜像中此符号链接被删除。三步排查法ls -l /usr/lib/x86_64-linux-gnu/libncursesw.so*—— 若无libncursesw.so.6即为根因dpkg -l | grep ncurses—— 确认libncursesw6已安装readelf -d /usr/local/bin/ccmake | grep NEEDED | grep ncurses—— 输出libncursesw.so.6证实链接需求。永久解决方案重建符号链接sudo ln -sf /usr/lib/x86_64-linux-gnu/libncursesw.so.6.3 /usr/lib/x86_64-linux-gnu/libncursesw.so.6此链接是libncursesw6包的标准内容手动创建无风险。5.5 问题在 Docker 容器中编译失败git clone报fatal: unable to access https://gitlab.kitware.com/...: server certificate verification failed现场日志Cloning into cmake... fatal: unable to access https://gitlab.kitware.com/cmake/cmake.git/: server certificate verification failed根因分析Docker 容器尤其 Alpine 或精简 Ubuntu 镜像缺少 CA 证书包ca-certificates导致 HTTPS 证书验证失败。git依赖curl或openssl验证证书而ca-certificates提供/etc/ssl/certs/ca-certificates.crt。三步排查法curl -I https://gitlab.kitware.com—— 若报curl: (60) SSL certificate problem即为根因ls /etc/ssl/certs/ca-certificates.crt—— 若不存在证实证书缺失update-ca-certificates—— 报command not found说明包未安装。永久解决方案在 Dockerfile 中添加RUN apt-get update apt-get install -y ca-certificates rm -rf /var/lib/apt/lists/*或在容器内执行sudo apt update sudo apt install -y ca-certificates此后git clone正常。5.6 问题cmake ..配置成功但make报错error: ‘std::filesystem’ has not been declared发生在Source/cmFileLock.cxx现场日志/home/user/src/cmake/Source/cmFileLock.cxx:123:10: error: ‘std::filesystem’ has not been declared 1