信浮沉最近在一台 Ubuntu 20.04 的服务器上重新部署 GIS 数据处理环境，核心任务就是把 GDAL 3.6.2 从源码编译安装起来。这个库做遥感与 GIS 的人基本都绕不开，但官方渠道的预编译包不一定能覆盖所有场景，尤其是内网离线环境、定制功能裁剪和版本锁定的需求。这篇就把我这次完整的编译实操过程、依赖链分析、configure 参数取舍，以及中间踩过的坑全部记录下来，给同样需要手动编译 GDAL 的同行做个参考。
1. 为什么要从源码编译 GDAL
1.1 系统包管理器和二进制的局限
很多人会问，apt 安装或者 conda 安装不是更快吗？确实快，但现实中问题不少。Ubuntu 20.04 自带的 GDAL 版本停留在 3.0.4，距离 3.6.2 差了整整三个大版本，部分新栅格驱动、COG 优化和矢量格式支持都没有。直接 apt 装，你只能得到一个很老的库，还得被迫接受系统预编译时的那一套依赖组合。
Python 生态里的 pip wheel 和 conda 包确实方便，pip install gdal==3.6.2 一条命令就能装完。但这类预编译包的痛点在于动态库版本被绑定得比较死，比如很多 wheel 依赖的 PROJ 版本是固定的，你项目里如果同时用了需要更高版本 PROJ 的其他库，就很容易出现动态库冲突。还有一个更现实的问题：很多生产服务器是内网隔离的，根本连不上公共软件源，这时候手里就只有一份源码包，不编译也得编译。
1.2 源码编译带来的实际收益
从源码编译最核心的优势就是可控。你可以指定 GDAL 版本，指定 PROJ、GEOS、OpenJPEG 这些关键依赖的版本，按需开启或关闭驱动，把整个库放进一个独立的前缀目录，用动态库搜索路径来管理，完全不影响系统自带的 GDAL。
举个例子，GDAL 编译时会尝试自动探测系统里的各种可选依赖，比如 PostgreSQL、MySQL、NetCDF、HDF5 等。如果通过 apt 安装的 GDAL，这些驱动一般都会默认开启或关闭，你没有选择权。而源码编译时可以明确用 --without-pg 这类参数把不需要的驱动关掉，既减少编译时间，也避免运行时加载一堆用不到的动态库。对像我这样需要在一个干净环境里搭建长期服务的场景来说，这种干净可控的状态非常重要。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 编译前的依赖准备与关键取舍
2.1 一套最常用的依赖清单
GDAL 3.6.x 的依赖体系主要分成三块：基础工具链、必选依赖、可选功能库。基础工具链就是 gcc、g++、make 这些，Linux 下通常已经装好，没有的话用 apt 一次装齐即可。必选依赖里有几个需要注意：PROJ（投影库，GDAL 3.x 强依赖，版本不能太老）、libtiff、libjpeg、libpng、libcurl、sqlite3、expat、libxml2。可选依赖就比较多了，比如 OpenJPEG 用于 JPEG2000、NetCDF/HDF5 用于科学数据格式、PostgreSQL/MySQL 用于数据库驱动。
我这次编译前的 apt 依赖安装命令是：
bash复制apt update
apt install -y build-essential pkg-config
apt install -y libproj-dev proj-bin
apt install -y libgeos-dev
apt install -y libtiff-dev libjpeg-dev libpng-dev
apt install -y libcurl4-openssl-dev
apt install -y libsqlite3-dev sqlite3
apt install -y libexpat-dev libxml2-dev
apt install -y python3-dev python3-setuptools
这里单独说一下 libproj-dev 的问题。Ubuntu 20.04 上通过 apt 装的 libproj-dev 是 7.2.1，理论上满足 GDAL 3.6 的最低要求（PROJ 6.0+），但实际用起来你会发现某些坐标转换功能行为不太对，而且后续如果系统升级或混用依赖库，很容易出现 PROJ 版本错乱的问题。我这次没有直接用系统自带的 PROJ，