李婧Amy发这篇博客的起因很简单：我最近在新环境里折腾地形数据处理，需要把 GDAL 3.6.2 完整编译进自己的项目目录，结果发现网上讲源码编译的教程要么版本太老、要么只讲了一半，根本没提依赖库的重要性。折腾了两天，踩了不少坑，最后总算把流程理顺了。这篇就当作一份整理笔记，给同样需要从源码编译安装 gdal3.6.2 库的朋友们抄作业用。
1. 为什么非要源码编译 GDAL 3.6.2 不可
1.1 系统包管理器解决不了的三个痛点
很多人第一反应是：直接 apt install 或者 pip install 多方便，为什么非得自己编译？这个想法没错，但如果你的项目对环境有严格要求，包管理器往往搞不定三件事。
第一是版本控制问题。操作系统自带的 GDAL 版本通常特别保守，比如 Ubuntu 22.04 仓库里的版本卡在 3.4.1，而某些新的栅格驱动、坐标转换算法只有 3.6+ 才有修复。你需要特定版本号，仓库里没有，那就只能自己动手。
第二是编译参数问题。做嵌入式部署或者写 C/C++ 后端服务的人最清楚，默认安装经常缺这个模块少那个驱动，比如想裁剪掉某些不需要的格式，或者说项目里同时引用多个 GDAL 版本，这时候一套带定制编译选项的源码构建就是刚需。
第三是路径隔离问题。我这次就是为了把 GDAL 独立装到 /opt/gdal/3.6.2 下，避免污染系统目录。这样以后想卸载或者切换版本，直接改环境变量就行，干净利落。
1.2 源码编译的核心逻辑：三步走
GDAL 的源码编译本质上就是三步：准备依赖 -> 配置构建参数 -> 编译安装。听起来简单，但每一步都有坑。
先说依赖。GDAL 本身是个庞大的库，底下挂了几十个可选依赖，比如 PROJ 管投影转换、GEOS 管几何拓扑运算、libtiff 管 TIFF 读写、SQLite3 管矢量数据存储。这些依赖直接决定了你编译出来的 GDAL 能支持哪些格式和算法。
再说配置。GDAL 从 3.x 开始已经全面推荐用 CMake 构建，相比老的 autotools 方式，CMake 的检查逻辑更直观，而且能自动处理不少依赖查找。但代价是参数特别多，光是 -D 开头的选项就有上百个，如果不清楚自己需要什么，很容易配出一个既不完整又编译不过的奇怪组合。
最后是安装。这一步比想象中容易出问题，尤其是动态库路径、头文件搜索路径没配好的话，编译倒是通过了，但运行 gdalinfo 直接报 libgdal.so: cannot open shared object file，这也是我这次踩得最深的坑之一，后面细说。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 编译前准备：工具链和依赖库清单
2.1 需要准备的工具链
编译 GDAL 3.6.2 需要一个可用的 C++ 开发环境，这一块每个平台略有差异，但核心就两样：编译器 + 构建工具。
我这次用的是 Linux 环境（Ubuntu 22.04，内核 5.15），所以直接装了整套开发工具包。如果你是 CentOS 或者 RHEL 系的系统，用 yum 也能装到等价的东西。Windows 用户注意，官方支持 MSVC + CMake + vcpkg 的组合，但流程完全不同，本文以 Linux 为主来讲。
先更新系统索引，然后安装 gcc、g++、make、cmake 以及 pkg-config 。如果你本地还没有这些基础工具，运行：
bash复制sudo apt update
sudo apt install -y build-essential cmake pkg-config
需要注意一点，GDAL 3.6.2 对 CMake 版本有最低要求，太老的 CMake 会直接报错不认 CMakeLists.txt。我建议至少装 3.16 以上，实测用 CMake 3.22 编译没有任何问题。
2.2 核心依赖库的作用和安装方法
这一节是源码编译的第一步，也是最容易被跳过但后果最严重的一步。GDAL 编译时如果找不到 PROJ，它不会报致命错误，而是默默编译出一个没有投影支持的精简版 GDAL。