用vcpkg在Ubuntu 18.04上装库第一次碰到CMake版本报错的时候我真的愣了一下。明明vcpkg一套流程走下来bootstrap也过了./vcpkg install gdal一执行configure阶段直接挂掉报错说CMake 3.10.2太旧。这台老服务器是Ubuntu 18.04系统自带cmake 3.10.2gcc 7.5.0都是几年前的默认版本。问题不在于库本身而在于工具链没跟上。这篇文章把我整个排查和解决过程完整记录下来包括怎么升级CMake、怎么顺手升级GCC、怎么清理vcpkg的残留缓存以及Ubuntu 18.04上其他几个我踩过的坑。如果你也在这类旧系统上用vcpkg建议把这篇存下来当操作手册翻。1. 问题背景老服务器上的vcpkg出师不利1.1 为什么还在用Ubuntu 18.04你可能想问都什么年代了还在用Ubuntu 18.04。现实是很多线上服务器、内部构建机、科研实验室的机器跑的就是这些老系统。系统Manager不轻易升级项目代码又依赖老环境动一发牵全身。与其折腾系统迁移不如在新系统上补工具链。我这次遇到的情况就是这样机器是Ubuntu 18.04.6 LTS内核和系统库都挺稳定就是开发工具链太老。这台机器上要做C数据处理打算用vcpkg管理第三方库结果第一道门槛就卡在CMake上。Ubuntu 18.04刚发布那个年代系统仓库里的CMake是3.10.2GCC是7.5.0。对当时的C项目来说够用但放在现在就明显吃力了。vcpkg里大量port已经要求CMake 3.19甚至更高不少新版本的库也要求编译器完整支持C17。所以在这个系统上用vcpkg不能直接用默认环境必须先手工升级工具链。1.2 我为什么设置VCPKG_FORCE_SYSTEM_BINARIESvcpkg默认会在首次使用时从发布站点下载预编译的CMake和Ninja到downloads/tools目录然后用自己的工具链构建库。这本是最省心的模式但我在的这台服务器没法直接访问外网的发布站点下载总是超时或失败。为了让vcpkg能跑起来我选择了配置环境变量VCPKG_FORCE_SYSTEM_BINARIES1强制vcpkg使用系统里已有的CMake和Ninja。这个环境变量的本意是方便离线环境或特殊网络条件的用户让vcpkg不要下载预编译工具转而依赖系统PATH里的cmake和ninja。如果系统里的版本够新这套配置完全没问题。问题就在于Ubuntu 18.04的系统CMake是3.10.2实在太老了。后来安装库时vcpkg用这个老CMake去配置那些新库的构建脚本直接触发版本检查报错。说实话这个坑最坑的地方是表面看是vcpkg坏了实际是系统工具链太旧。1.3 直观报错是什么样当时执行./vcpkg install gdal日志刷到最后卡在configure阶段核心报错大概长这样CMake Error at CMakeLists.txt:30 (cmake_minimum_required): CMake 3.10.2 is below required version 3.19第一反应以为是vcpkg的port写错了或者缓存出问题。后来仔细一看报错里的CMake版本3.10.2就是系统的/usr/bin/cmake版本。也就是说vcpkg真的按VCPKG_FORCE_SYSTEM_BINARIES的设置去用了系统CMake而系统CMake满足不了这个库的最低版本要求。2. 报错现场与初步排查2.1 核对工具链版本遇到这种报错不要急着改代码或者删缓存先把环境摸清楚。我第一件事就是确认当前shell里的各个工具版本which cmake cmake --version which ninja ninja --version gcc --version g --version结果很明显/usr/bin/cmake指向CMake 3.10.2ninja存在版本1.8.2gcc/g7.5.0这三个加在一起基本宣告了直接装新库会困难重重。老版Ninja 1.8.2倒还能凑合用但CMake 3.10.2对现代CMake语法支持差得太多尤其是很多库的CMakeLists里用了cmake_minimum_required(VERSION 3.19)这种做法直接拒绝执行。2.2 检查vcpkg工具链逻辑我当时的怀疑点是vcpkg里是不是有一个环境变量或triplet设置让vcpkg误用了系统cmake。于是翻了下scripts/cmake/vcpkg_configure_cmake.cmake核心逻辑其实不复杂vcpkg在构建库时会从自己的downloads/tools目录找预编译CMake找不到或强制系统模式时才回退到系统CMake。我设置了VCPKG_FORCE_SYSTEM_BINARIES1所以它直接选择了系统CMake。我又试着临时取消这个环境变量让vcpkg正常走默认下载逻辑结果它一直在尝试连接外网下载工具几次都卡住超时。这样反而更费时间。所以问题的解决方向就落在了另外一条路上既然系统工具链版本太低那就升级系统工具链让vcpkg在强制系统模式下也有足够高的版本可以用。2.3 结论是CMake版本卡住不是库本身的问题排查走到这一步结论已经比较清晰库本身没问题vcpkg的port也没问题纯粹是系统CMake版本太旧。而且这个卡点还很顽固因为vcpkg在configure阶段做版本检查版本不满足就直接abort不会给你临时绕过或者降级的机会。这里我也顺带想到了编译器版本的问题。CMake过关之后GCC 7.5对C17特性和部分C20特性的支持也不完整。GDAL这类库虽然保守但新版本内部已经用了不少C17特性GCC 7.5可能让编译阶段报出一堆莫名其妙的模板错误。为了避免装到一半又翻车我决定把GCC也一并升级。3. 治本方案源码编译升级系统CMake3.1 安装编译CMake所需的系统依赖CMake本身可以用源码编译安装这个过程并不复杂但依赖要先装齐。我用的是CMake 3.29.4这个版本它对系统库的依赖主要是OpenSSL和cURL以及其他基础库。执行sudo apt-get update sudo apt-get install -y libssl-dev libcurl4-openssl-dev zlib1g-dev如果你还想让CMake支持Qt GUI界面可以加装qtbase5-dev但服务器上完全没有必要装不带GUI的版本更省心。另外源码编译会用到Make和GCC这些Ubuntu 18.04默认就有不用额外装。我踩过一个小坑如果只装libssl-dev而不装libcurl4-openssl-devCMake编译时虽然不会报错但生成出来的cmake -P脚本在处理远程下载测试时可能有问题。所以按上面几个包装齐是最稳的。3.2 下载、编译与安装从官网下载源码包。记住选择稳定版不要下载rc版本避免一些隐蔽bugwget https://cmake.org/files/v3.29/cmake-3.29.4.tar.gz tar -zxvf cmake-3.29.4.tar.gz cd cmake-3.29.4接下来是关键的配置步骤。CMake源码目录下有一个bootstrap脚本类似Linux内核的configure。指定并行数编译可以快不少./bootstrap --parallel4 make -j4 sudo make installbootstrap这步会做很多自我检测五六分钟很正常别以为卡死了。整个过程如果顺利最后CMake会安装到/usr/local/bin目录下和系统自带的/usr/bin/cmake共存。默认情况下/usr/local/bin在/usr/bin前面所以新版本会自动优先生效。3.3 校验版本是否真的生效安装完成后立刻验证一下同时让shell重新查找命令路径hash -r which cmake cmake --version正常情况下which cmake应该指向/usr/local/bin/cmake版本显示3.29.4。我还专门用/usr/bin/cmake --version对比了一下确认老的3.10.2确实还在只是不再被优先调用。这里有一个细节值得注意如果你用sudo make install安装CMake后在你自己的用户shell里执行cmake --version还是老版本先别急着说安装失败。用hash -r清掉shell的命令哈希缓存再退出重开一个终端一般就能看到新版本。实在不行检查一下PATH环境变量确保/usr/local/bin在/usr/bin前面。4. 未雨绸缪顺手升级GCC编译器4.1 Ubuntu 18.04升级GCC的正确姿势Ubuntu 18.04自带的GCC是7.5.0完整支持C17其实还差一些边角。为了避免vcpkg后续编译某些新库时在模板实例化和标准库特性上报错我决定把默认编译器升级到GCC 9。GCC 9对C17支持已经很完整对C20的个别特性也有部分支持和vcpkg里大部分port的兼容性非常好。在Ubuntu 18.04上用Toolchain test PPA是最省事的方式。这个PPA专门提供较新的工具链版本相当于是为老系统补充新版编译器的官方渠道。执行sudo add-apt-repository ppa:ubuntu-toolchain-r/test -y sudo apt-get update sudo apt-get install -y gcc-9 g-9需要注意Ubuntu 18.04的Python环境和add-apt-repository可能没装。如果提示命令不存在先执行sudo apt-get install -y software-properties-common补上。此外添加PPA后apt-get update有时会因为网络问题报错多试几次或者切换到国内的镜像源不然这个PPA一直拉不下来。4.2 切换默认编译器版本安装完gcc-9和g-9后系统不会自动把默认编译器切换过去需要手动设置。我用了update-alternatives这是Debian/Ubuntu系管理多版本工具链的标准方式sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-9 100 sudo update-alternatives --install /usr/bin/g g /usr/bin/g-9 100之后执行gcc --version g --version都会显示9.x版本。我还保留了原来的GCC 7.5没删万一有的老项目需要旧编译器可以通过update-alternatives再切回去。这里要提醒一句update-alternatives的优先级参数很重要我给gcc-9设置了100比gcc-7的默认优先级高系统才会默认选gcc-9。如果以后还要装gcc-10或gcc-12记得调整优先级否则切了半天还是老版本白折腾。4.3 验证编译器环境升级完编译器我确认了一下C标准库的头文件路径和版本避免出现头文件与libstdc库不匹配的情况。实际项目里常见的一种坑是这样的GCC切换了但CMake的缓存里还记录着旧编译器路径编译时用了gcc-9却链了老的libstdc导致各种诡异链接错误。验证方法很简单执行一个小程序或者直接echo | gcc -E -dM -看宏定义。我在实践里是直接编译了一个用了C17特性的测试文件#include filesystem #include iostream int main() { std::filesystem::path p(/tmp); std::cout p.filename() std::endl; return 0; }GCC 7.5对filesystem的支持还不成熟能编译通过说明环境和标准库是匹配的。测试通过后我才继续下一步。5. 重新安装库并接入项目5.1 清理失败遗留的缓存和构建目录升级完CMake和GCC后不能直接重新跑./vcpkg install gdal因为vcpkg里有几处残留可能干扰新构建buildtrees目录存放上一次构建的临时文件一些configure的产物已经按老CMake生成了留着会污染新构建packages目录未完成安装的半成品downloads目录如果之前下载过损坏的源码包也可能被复用我习惯性地手动清理rm -rf buildtrees/gdal packages/gdal如果更彻底一点可以把整个buildtrees目录删掉代价是下次所有库都要重新编译比较费时间。我这次只删了对应库的目录够用。还有一种做法是执行./vcpkg remove gdal --recurse先移除依赖关系但我没采用因为当前没有安装成功没有完整依赖树可卸。5.2 重新执行安装清理之后重新执行安装命令./vcpkg install gdal这次configure阶段能顺利通过不再报CMake版本过低。随后是漫长的编译过程GDAL这种库体积大依赖也不少在4核机器上编译了大概20多分钟。期间会有很多warning只要不是error就继续跑。编译完成时vcpkg会输出类似这样的信息gdal:x64-linux is installed.到此问题基本解决。顺便验证一下新的工具链是否全程生效在vcpkg编译日志里configure阶段会显示用的CMake路径和编译器版本我特意看了一眼确认是/usr/local/bin/cmake和gcc-9。这一步很有必要不然你永远不知道它到底用的哪个版本。5.3 在项目里集成安装好的库vcpkg装完库之后最常用的集成方式是在CMake项目里指定工具链文件cmake -B build -DCMAKE_TOOLCHAIN_FILE/path/to/vcpkg/scripts/buildsystems/vcpkg.cmakeCMakeLists里通过find_package找到对应库find_package(GDAL REQUIRED) target_link_libraries(my_app PRIVATE GDAL::GDAL)需要注意find_package(GDAL REQUIRED)里的组件名、target名在不同版本的库之间可能变化具体以vcpkg安装完成后打印的提示文档为准。我这次就是调用gdal_info确认了库能正常工作再用一个测试程序验证了链接通过。整个过程走完vcpkg在老系统上就算真正能用了。6. 问题速查Ubuntu 18.04老环境还有哪些坑6.1 GLIBCXX版本不兼容这是Ubuntu 18.04上很经典的一个问题。有时候你升级了GCC和CMake但运行vcpkg或某些预编译工具时还会报类似这样的错误/lib/x86_64-linux-gnu/libstdc.so.6: version GLIBCXX_3.4.26 not found原因很简单预编译工具比如新版的ninja是用较新版本GCC编译出来的运行时需要更高版本的libstdc。而系统默认的libstdc来自GCC 7.5里面的GLIBCXX版本符号不够新。解决办法是升级系统的libstdc仍然可以用Toolchain test PPA提供的gcc-9来更新sudo apt-get install -y libstdc-9-dev装完后用下面的命令检查是否包含所需版本的符号strings /usr/lib/x86_64-linux-gnu/libstdc.so.6 | grep GLIBCXX如果你看到GLIBCXX_3.4.26或更高版本说明问题解决。这个坑很容易被忽略因为它不像CMake版本那么直观。我建议在Ubuntu 18.04上只要升级GCC就顺手把libstdc-9-dev装上免得后续装一个库就报一次错。6.2 系统依赖和pkg-config问题很多库在configure阶段会依赖系统里的第三方库比如zlib、openssl、libpng、pkg-config等。Ubuntu 18.04系统自带的这些库版本偏老但大部分情况下能兼容vcpkg编译出来的新库。我遇到的比较典型的问题是缺少pkg-config一些port在查找系统库时会调用pkg-config来获取编译参数没有这个命令直接报错。尽早装上sudo apt-get install -y pkg-config另外如果你安装的库依赖新版OpenSSL这里要特别提醒Ubuntu 18.04自带的OpenSSL版本还算新但vcpkg很多时候不会用系统的OpenSSL而是自己编译一份。这样做的好处是可控坏处是编译时间变长磁盘占用变大。如果不想让vcpkg编译OpenSSL可以尝试设置VCPKG_USE_SYSTEM_OPENSSL1但效果因库而异我通常不折腾这个配置直接让vcpkg自己来。6.3 要不要用容器作为Plan B如果老服务器上的问题实在太多或者有些二进制依赖版本要求非常新短期又不想继续在系统层面折腾可以考虑用Docker跑一个较新版本的Ubuntu开发环境。比如用Ubuntu 20.04或22.04的容器直接在容器里安装vcpkg工具链版本都正常能省掉大量编译和排查时间。但容器方案也有代价如果你的vcpkg缓存和编译产物要长期保留Docker容器一旦删除就全没了需要额外挂载数据卷。另外有些库需要访问宿主机设备或内核模块容器里可能没法正常工作。对我这次的场景来说升级系统工具链更直接因为服务器后续还要承担生产任务容器只是临时方案。如果你只是做一次性编译容器会更快如果是长期维护项目建议一步到位升级系统工具链。6.4 VCPKG_FORCE_SYSTEM_BINARIES的副作用最后专门说下VCPKG_FORCE_SYSTEM_BINARIES1这个变量。它确实能让vcpkg在离线或受限网络环境下工作但副作用也明显vcpkg不再保证使用自己的工具链版本完全依赖系统环境。一旦系统的CMake或Ninja版本太旧就可能出现我前面遇到的问题。如果你在使用这个变量建议把系统工具链里的CMake、Ninja、GCC都升级到vcpkg的可接受范围内再继续。另外这个变量只是影响工具的来源不影响vcpkg安装的库的版本。不要在配置里把这个变量永久写进~/.profile或CMake工具链文件里只在需要离线构建时临时设置更容易控制环境变量作用域。我这次就是因为之前把变量写进了shell配置文件导致排查时一度忘记是它引起的绕了些弯路。7. 一点实际操作中的体会这次在Ubuntu 18.04上折腾vcpkg最终解决问题的不是某个神奇参数而是老老实实把工具链版本补齐。CMake升级到3.29GCC升级到9libstdc同步更新vcpkg安装库就顺畅多了。现在回想起来最值得记录的经验有三条第一遇到vcpkg安装报错先别急着删缓存、改配置先确认当前shell里cmake、ninja、gcc这些实际生效的版本做到心里有数。很多诡异问题根源就是工具链新旧混搭。第二升级工具链要同步到位不要只升CMake不升GCC。vcpkg里不少库的configure和编译阶段对编译器特性都有要求CMake过了GCC也可能成为下一道坎。一次性把GCC和libstdc都升好能避免反复折腾。第三老系统的工具链升级路径其实很有规律CMake走源码编译GCC走Toolchain test PPA。这两条路都成熟可靠按步骤操作不会出大问题。不要把时间花在寻找所谓的“一键脚本”或“兼容包”上那才是真的浪费时间。如果你也有一台Ubuntu 18.04服务器要跑vcpkg希望这篇记录能帮你少走几步弯路。工具链版本这种基础问题看起来不起眼但卡住的时候是真的让人头大。