Windows下MinGW-w64编译GDAL 2.4.4：部署与配置实战

简介：面向Qt5+MinGW64开发者的GDAL 2.4.4预编译包，可直接集成到Windows 64位环境，省去手动编译的繁琐步骤，同时作为广泛应用的开源地理空间数据处理库，此包支持的栅格与矢量格式众多，能覆盖大部分GIS与遥感数据读写需求。压缩包共188个文件，以头文件（.h）、MinGW64库文件（.a/.dll）、命令行工具（.exe）及坐标系参数文件（.csv/.wkt）为主，整体大小约90.14MB，其中头文件与库文件用于Qt工程链接调用，exe工具可独立进行格式转换与数据处理，csv等参数文件则提供投影与基准面定义。目前已有291人学习/下载。解压后可直接在Qt工程中链接GDAL，调用栅格/矢量数据格式的读写接口，并借助附带的gdal-config脚本、示例代码与配置文档快速上手。这份资源适合需要处理地理空间数据或构建GIS应用的C++开发者，能够显著降低环境配置成本，将精力聚焦于业务功能实现，同时清晰的目录结构也便于按需检索与二次开发。

1. 项目概述与背景

1.1 核心需求解析

先把"gdal244_mingw64.rar"这个标题拆开看：gdal244指的是 GDAL 2.4.4 版本，mingw64指 MinGW-w64 编译器套件。两件事放一起，意思很直白——这就是一份在 Windows 64 位环境下、用 MinGW-w64 编译器构建好的 GDAL 2.4.4 库压缩包。对于经常和地理空间数据打交道的人来说，这个包的价值在于：它把 GDAL 的编译成果直接固化成一个可分发、可复用的文件，你不需要自己从头搭编译环境、处理依赖冲突，解压即可用。

我为什么专门写这个版本而不是更新的 GDAL 3.x？因为 GDAL 2.4.x 是目前很多老项目、生产系统的默认依赖。尤其是 Python 绑定、QGIS 插件、以及一些基于 OGR 做矢量数据处理的业务逻辑，很多还是按 2.4 的 API 写的。如果贸然升到 3.x，一些弃用的接口和编译选项差异会让旧代码直接跑不起来。所以对很多团队来说，在 64 位 Windows 环境下保留一份可用的 2.4.4 编译产物，是维持旧系统稳定运行的低成本方案。

1.2 适用场景与受益人群

说直白点，如果有人发给你一个gdal244_mingw64.rar，你大概率处在下面几种情况之一：

• 你是开发或运维，要在一台没有配好 GDAL 环境的新 Windows 机器上快速部署一个依赖 GDAL 的服务。
• 你拿到一份历史项目源码，CMakeLists.txt里写死了find_package(GDAL 2.4 REQUIRED)，或者 Makefile 里硬编码了gdal-config路径。
• 你需要用 MinGW-w64 编译 C/C++ 程序并静态/动态链接 GDAL 2.4.4 的库。
• 你在折腾 Python 的osgeo绑定，但 pip 安装的 GDAL wheel 在特定编译器环境下总是出ImportError，想干脆自己编一份对应版本的底层库。

这次我就以“拿到并部署使用一份 MinGW-w64 构建的 GDAL 2.4.4 包”为主线，把从解压、配置路径、验证功能，到处理最常见的 Git SSL 证书报错和运行时 DLL 缺失问题的完整流程走一遍。这篇文章写给两类读者：一是准备快速上手 GDAL 开发的入门者，二是维护老项目被环境问题折腾过的实操派。

2. 为什么需要一份预编译的 GDAL 包

2.1 从源码编译 GDAL 的隐性成本

如果你问 GDAL 官方文档，它当然推荐你下载源码自己编。但现实中，在 Windows 上用 MinGW-w64 从零编译 GDAL 2.4.4，往往不是"执行三个命令"那么简单。你得先处理 PROJ（投影库）、GEOS（几何引擎）、LibTIFF、LibPNG、SQLite 这些依赖，每一个都得单独 configure、make、install。即便你照着文档走，也容易在以下环节卡住：

• MinGW-w64 的库文件在 64 位环境下有lib与lib64的目录区分，某些依赖库的 find 脚本并不兼容。
• GDAL 2.4 的 configure 脚本对 MinGW 的检测在某些 shell 环境下会误判编译链，生成错误的 Makefile。
• 官方预编译 Windows 二进制包大多基于 MSVC 编译，C 运行时（msvcrt vs mingw 的 libgcc）不一致，混用容易导致内存崩溃或接口不匹配。

所以社区里出现了一个不成文的做法：谁编出来一套能用的组合，就打个包共享给同事或开源社区。gdal244_mingw64.rar就是这种产物，它的存在价值在于跳过上面所有不可控的编译过程，直接把目标环境"归一化"。

2.2 基于 MinGW-w64 而非 MSVC 的取舍

我特别强调它基于 MinGW-w64，而不是 MSVC。这背后的差异很关键：GDAL 的 Python 绑定（osgeo）和部分 C 扩展模块，是依赖 C 编译器的 ABI 兼容性的。如果你的系统里装的是 MinGW 系列工具链（比如 Code::Blocks、Dev-C++、MSYS2 环境），那用 MSVC 编译的 GDAL 库就存在跨编译器调用的风险，最典型的表现是程序一调用 GDALOpen 就崩溃，或者内存释放时校验和报错。而基于 MinGW-w64 编译的 GDAL 包，能被同一套 MinGW 工具链无缝链接，没有 ABI 隔阂。

另外在 Windows 下，MinGW-w64 编译出的程序不依赖 MS Visual C++ Redistributable，部署时少装一个运行时组件，这在服务器上做绿色化部署时特别省心。所以如果你已经选择了 MinGW 路线，gdal244_mingw64就是和你的工具链最匹配的那块拼图。

3. 解压与目录结构搭建

3.1 快速验证压缩包是否完整

拿到gdal244_mingw64.rar，第一步不是急着解压，而是检查包内结构是否完整。用 RAR 工具打开后，我建议先看根目录下有没有这三个关键子目录：

如果缺少include或lib，这包就只能跑命令行工具，无法作为二次开发的库使用。拿到包后，建议先在bin目录下找gdalinfo.exe，之后所有验证都从它开始。

3.2 推荐目录放置位置

我测试过不同的解压路径，这里直接给结论：放在D:\gdal244_mingw64或者C:\gdal244_mingw64这种盘符根目录下，越短越好。为什么？因为 GDAL 的配置和构建脚本里，很多地方会拼绝对路径，路径深度一旦超过两层，某些旧版脚本里的路径字符串存储空间就会溢出，报错还特别隐晦。另外，Git 默认的 MinGW 环境有时候会踩到证书文件路径问题，这个后面专门讲，路径短能少很多莫名其妙的麻烦。

解压完成后，后续所有命令行的使用都需要能定位到bin下的 DLL。建议把D:\gdal244_mingw64\bin永久加入系统的PATH环境变量。如果条件不允许改全局环境变量（比如没管理员权限），退而求其次的做法是写一个批处理脚本，每次使用前临时设置 PATH：

@echo off set PATH=D:\gdal244_mingw64\bin;%PATH% set GDAL_DATA=D:\gdal244_mingw64\share\gdal set PROJ_LIB=D:\gdal244_mingw64\share\proj gdalinfo --version

这段脚本里的GDAL_DATA和PROJ_LIB是后面验证数据文件路径的关键，漏掉任何一个，后续跑gdalwarp或ogr2ogr转坐标系时都会报错找不着 datum 定义。

提示：不要图省事把 GDAL 的 bin 目录直接复制进 MinGW 或 Git 的安装目录里。多个版本的 DLL 混在同一目录会引发运行时加载到错误版本的问题，排查起来极其痛苦。

4. 配置与功能验证

4.1 检查版本与驱动支持

打开命令行（前提是前面的 PATH 设置已完成），执行：

gdalinfo --version

正常情况下会输出类似GDAL 2.4.4, released 2020/01/08的信息。如果输出版本号异常，比如出现GDAL 3.x，说明你 PATH 里可能还有其他版本的 GDAL 出现在前面，需要调整优先级。这个细节几乎是我遇到过的最高频事故，特别是机器上装了 QGIS 或者 Anaconda 的情况下，这些软件自带捆绑 GDAL 并会抢先注入 PATH。

接着检查驱动支持列表，这是判断库是否完整的重要依据：

gdalinfo --formats | grep -E "GTiff|GPKG|ESRI Shapefile|MBTiles"

在 GDAL 2.4.4 中，能同时看到GPKG（GeoPackage）和MBTiles驱动，说明常见的矢量、栅格格式都有覆盖。如果格式列表明显很短，比如连 ESRI Shapefile 都没有，那这个包大概率是被阉割过的，或者编译时禁用了很多驱动，这种包适合自己特定使用，但不建议做通用开发基础。

4.2 坐标转换数据路径配置

GDAL 2.4 在编译时如果依赖了 PROJ。4 或更新版本，运行时需要能找到proj.db或者旧的epsg文件。这个数据文件如果缺失，直接的症状是调用OGRSpatialReference::SetFromUserInput("EPSG:4326")或gdaltransform命令时，输出坐标全部为inf或nan，而且命令行不给任何警告。

在gdal244_mingw64这个包中，proj 数据可能被打包在share\proj目录。我用一个简单的坐标转换测试实际验证一下：

echo 116.391 39.907 | gdaltransform -s_srs EPSG:4326 -t_srs EPSG:3857

正常输出应该落在 Web Mercator 坐标系的大致范围内（约12958175 4751711附近），如果输出是0.000000 0.000000，不用怀疑，就是PROJ_LIB没设置对。在 Windows 系统上，设置PROJ_LIB环境变量时要注意，新版 PROJ（6.0+）使用的是proj.db二进制数据库，旧版使用文本文件epsg。GDAL 2.4.4 如果静态链接旧版 PROJ，它找的是epsg文件；编译时动态链接 PROJ 6，就会要求proj.db。我的经验是：不管哪种情况，都直接将环境变量指向share\proj目录，让库自己决定加载什么，最稳妥。

set PROJ_LIB=D:\gdal244_mingw64\share\proj

设置完成后，再次运行上面的 gdaltransform 命令验证输出。正常输出应该落在 Web Mercator 坐标系的大致范围内（如x=12958175左右），如果还是输出全 0，就到share\proj里看看是否有proj.db或epsg文件。缺哪个补哪个，有时候直接从另一台机器的 PROJ 安装目录复制一份就能修复。

5. MinGW-w64 与 Git 证书环境问题排查

5.1 报错现场还原

这次的热词里反复出现一段 git 报错，我不能忽略，因为它在 MinGW-w64 环境下极其典型。原始报错形如：

unable to access 'https://xxx.git/': error setting certificate file: d:/git/mingw64/etc/ssl/certs/ca-bundle.crt

表面上是 Git 无法加载 CA 证书文件，但很多人忽略的是：这个"d:/git/mingw64"不是系统级 MinGW 路径，而是 Git for Windows 内置的 MinGW-w64 环境。报错出现的原因是 Git 被配置成读取一个不存在或损坏的证书文件，而配置的存在，往往是因为 GDAL 的某些构建脚本或 CMake 工程在运行时会临时篡改全局 Git 配置，指向了预期包含证书、但实际没放证书的路径。

5.2 系统性解决方案

解决这个问题，按下面顺序排查，每一步都是实际踩坑后的经验总结：

1. 检查全局 Git 配置。在 Git Bash 里执行：

git config --global --list | grep ssl

如果输出包含http.sslCAInfo=...，且路径明显指向不存在的文件，直接删除这条配置：

git config --global --unset http.sslCAInfo

2. 确认实际证书文件位置。打开文件管理器，进入C:\Program Files\Git\mingw64\etc\ssl\certs\（注意这里可能是 Git 安装目录下的 mingw64），找ca-bundle.crt是否存在。Git for Windows 自带的这个文件通常是有效的，只不过很多开发者在编译 GDAL 时误将 Git 的路径写进了环境变量，然后把另一套 MinGW 安装包放在前面，导致所有链接操作都指向了一个没初始化证书库的目录。

3. 如果路径确实缺失。可以用 Git 安装目录下那个带时间戳的证书文件复制一份过去：

cp "/c/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt" "/d/git/mingw64/etc/ssl/certs/ca-bundle.crt"

注意备份原文件，因为目录路径不同可能导致覆盖失败，需要先确认d:/git/mingw64目录结构是否真实存在。

这个问题的本质，是你在同一台机器上装了多套 MinGW 环境（Git 自带一套、你手动装的 MSYS2 一套、某些 IDE 又带一套），环境变量 PATH 的先后顺序决定了 git 到底去找哪一家的证书库。对于 GDAL 开发，我的建议是：固定使用同一套 MinGW 环境，不要让 Git 自带环境与手动安装的 MSYS2 混用。

6. 编译链接与程序集成实操

6.1 用 MinGW-w64 编译器链接 GDAL 库

假设你有一个用 C++ 写的 GIS 小程序，要用 GDAL 读取 TIFF 的影像尺寸，那么在gdal244_mingw64的环境下，编译命令可以这样写：

g++ test.cpp -I D:\gdal244_mingw64\include -L D:\gdal244_mingw64\lib -lgdal -o test.exe

这一步要注意，-lgdal链接的库需要与你的程序编译目标位数一致。如果你用的 MinGW-w64 编译器是 64 位，但 GDAL 包是 32 位，链接会直接报undefined reference或file not recognized。验证当前编译器位数的方式很简单：

g++ -dumpmachine

输出应该包含x86_64-w64-mingw32，才是与mingw64对应的 64 位环境。如果输出是i686-w64-mingw32，那你拿到的是 32 位工具链，要么换编译器，要么找 32 位版本的 GDAL 包，否则后边编译全部白搭。

6.2 动态链接库（DLL）搜索路径问题

用 MinGW 编译出的程序，运行时会按以下顺序查找 DLL：可执行文件所在目录、当前工作目录、系统 PATH 目录。如果你把test.exe放在一个没有 GDAL DLL 的目录里，运行时大概率弹窗报"找不到 libgdal-20.dll"。这里强调一下版本后缀：GDAL 2.4 的动态库文件名为libgdal-20.dll，如果你看到的是libgdal-26.dll，说明包其实是 3.6 版本，与标题不符，要核实包的版本。这种"标题版本与实际版本不符"的现象在网络下载包里并不罕见，一定要核实清楚。

考虑到部署的便捷性，我倾向于在最终发版的目录里，把bin下所有 DLL 直接复制到 exe 同目录。这样保证程序在目标机器上不依赖系统 PATH 配置就能直接运行。唯一要注意的是，DLL 有一箩筐（gdal 的依赖库包括libcurl-4.dll、libproj-15.dll、libgeos_c-1.dll、libtiff-5.dll等），如果只挑着复制，漏掉一个依赖，运行时会报The code execution cannot proceed because xxx.dll was not found。与其一个一个试，不如一次性全量复制，总大小没多大，省去无数测试时间。

6.3 静态链接方式与独立部署

如果你希望最终交付的程序是单文件，不依赖任何外部 DLL，那就要用libgdal.a做全静态链接。编译时调整一下：

g++ test.cpp -I D:\gdal244_mingw64\include -D_STATIC_LIB -L D:\gdal244_mingw64\lib -lgdal -lproj -lgeos_c -ltiff -lpng -lsqlite3 -o test_static.exe

这种方式编出的 exe 体积会膨胀很多，但好处是部署到任何一台 Windows 机器上都能直接运行，不用再关心 GDAL 环境是否齐全。静态链接时我踩过的坑是宏定义必须写：-D_STATIC_LIB或-DGDAL_STATIC，具体哪个取决于包编译时的导出宏约定，如果不写，编译可能通过但运行时报"链接错误"或者"找不到入口"。如果两种宏都不确定，可以直接查看include\gdal_priv.h里是否有#ifdef GDAL_STATIC的预处理分支，按那个宏来定义即可。这段经验常规文档不会写，但实际编译时非常关键。

7. 在 CMake 工程中引用这个 GDAL 包

7.1 手动设置 CMake 查找路径

CMake 提供了find_package(GDAL REQUIRED)机制，但默认情况下，它只在系统标准路径和 PATH 的辅助路径里查找gdal-config或GDALConfig.cmake。对咱们这份gdal244_mingw64包，如果它是按官方 CMake 配置安装的，包里应该有cmake子目录或GDALConfig.cmake文件。在CMakeLists.txt里最省事的写法，是直接指定查找前缀：

set(GDAL_DIR "D:/gdal244_mingw64") set(CMAKE_PREFIX_PATH ${GDAL_DIR}) find_package(GDAL REQUIRED) include_directories(${GDAL_INCLUDE_DIRS}) target_link_libraries(your_target ${GDAL_LIBRARIES})

但要注意，如果这个包里的GDALConfig.cmake写得比较老派，它可能不会设置GDAL_INCLUDE_DIRS和GDAL_LIBRARIES变量，而是改用GDAL_INCLUDE_DIR和GDAL_LIBRARY。这两种变量命名差异会导致 find_package 成功但链接时找不到库。保险起见，在 find_package 之后打一行 debug：

message("GDAL Include: ${GDAL_INCLUDE_DIRS}, Lib: ${GDAL_LIBRARIES}")

编译一次就能看到具体设置了什么，再针对性调整。

7.2 老式 Makefile 手动链接的兼容写法

有些 2019 年前后的老项目用的是 Makefile 加gdal-config的写法。在 Windows 的 MinGW 环境下，没有 Linux 上的/usr/bin/gdal-config，但包里可能会带一个gdal-config脚本。可以直接手动指定它的全路径来模拟：

GDAL_CONFIG = D:/gdal244_mingw64/bin/gdal-config GDAL_CFLAGS := $(shell $(GDAL_CONFIG) --cflags) GDAL_LIBS := $(shell $(GDAL_CONFIG) --libs)

如果脚本执行报错，多半是因为它依赖 bash 环境，那就在 Git Bash 或 MSYS2 的 shell 里跑 make，而不是 cmd。这类 cgo 或 Makefile 项目的“环境玄学”问题，九成都是 shell 环境不对导致的，换回 bash 跑，立竿见影。

这里要特别提醒：绝对不要在项目里写死/usr/local/lib或者C:/Program Files/GDAL这类硬编码路径，你是在用解压包，不是在系统级安装，路径必须跟实际解压位置一致。写成相对路径或者通过环境变量注入的方式，能保证项目换台电脑还能继续编译。

8. 常见问题速查与解决方案

下面这些坑是我在多次部署和验证这个包的过程中整理出来的，按问题现象排列，每条都给了可直接执行的解决方案：

排查这类环境问题的通用方法论，我总结下来就一句话：先确认你实际执行的是哪个文件，再讨论为什么它出错。用where、which、echo %PATH%这些基础命令把现场弄清楚，能避免大半无效操作。

9. 关于 GDAL 2.4.4 的维护与后续扩展

9.1 老版本并不等于不值得维护

现在 GDAL 主线已经到 3.x，甚至 3.8、3.9 都出了，为什么还有人要找 2.4.4 的包？我接触到的真实原因集中在以下几类：

• 空间数据库中间件或者 C++ 委托库是基于 2.4 的 OGR API 写的，升级到 3.x 后OGRFeature的内存管理和字段类型判断行为有细微变化，线上数据入库逻辑表现不同。
• 项目组内交付的算法模型是基于 2.4 编译的，为了保证 AI 推理环境和数据预处理环境一致，避免坐标转换结果出现毫米级漂移，宁可锁死版本。
• 冷门系统兼容性，部分国产化操作系统环境里，自带的 GDAL 版本库就是 2.4.x，你本地开发如果用 3.x，编出来的算法到生产环境就跑不了。

老版本像旧钥匙，只适配旧锁。只要锁没换，钥匙就有价值。gdal244_mingw64作为一把编译好的钥匙，它的生命周期会伴随那些"锁"一直延续下去。

9.2 是否值得把项目升级到更新的 GDAL

当然，如果你维护的项目还没有绑定死 2.4 的 API，我个人建议尽早评估升级到 3.6+。GDAL 3.x 在栅格计算、矢量编辑、坐标转换精度上前进了一大步，尤其对EPSG:3857、EPSG:4326之外的高精度局部坐标系支持更完整。但从 2.4 升到 3.x 不是改个版本号就行，你要重点检查三点：是否还在用被删除的旧驱动（如PCIDSK的某些函数接口）、是否依赖OGRSpatialReference::morphFromESRI的旧返回行为、以及是否有直接访问 GDAL 内部数据结构的代码。这些改造成本，远比找一个 2.4.4 的现成包高得多。

所以我的建议是：在生产系统稳定的前提下，保留 2.4.4 作为兼容层，用独立的虚拟环境或目录隔离 3.x 的新项目。两个版本并存不冲突，只要你让它们的 PATH 环境互不干扰、链接路径分开写。这也就是为什么bin目录和 DLL 全量复制到项目目录的做法这么重要——它天然实现了一套代码一个版本环境，谁也不会覆盖谁。

最后再分享一个小技巧：如果你需要频繁在 2.4 和 3.x 之间切换，可以在系统里保留两个解压目录，然后用一个切换批处理脚本统一修改PATH、GDAL_DATA、PROJ_LIB三个环境变量。这个脚本放桌面上，跑一次切换一次，比每次手动改环境变量省事得多。我在实际维护多个老项目时就用这个方法，一天切几十次也不会出错。

这篇就写到这里。gdal244_mingw64.rar本身只是一个压缩包，真正值钱的是你知道怎么把它变成长得像样的服务、编译产物和可用工具链。把这篇里的每个命令跑一遍，排掉坑，你就是团队里那个"搞 GDAL 环境最稳的人"。

本文还有配套的精品资源，点击获取