简介这份资源是作者在 Windows 环境下使用 msys2 配合 mingw64 工具链编译完成的 GDAL 1.11.5 库面向需要在 QtMinGW 版本中进行 C 地理空间开发、又不愿自行折腾编译环境的开发者。解压后将 bin 目录加入系统环境变量并在 .pro 文件中配置 GDAL 即可直接调用省去从源码编译的繁琐过程。压缩包共 149 个文件约 70.71MB包含 63 个 h 头文件、28 个 csv 数据表、22 个 exe 工具程序以及 a 静态库、dll 动态库、pc 配置文件和 gdal-config 脚本等覆盖开发所需的头文件、链接库与坐标数据。目前已有 1516 人学习下载。资源内附常见程序异常结束的排查思路指引方便读者快速定位运行期问题适合 GIS 方向的中初级 C 开发者直接集成使用。1. mingw64 编译 GDAL 1.11.5为什么老版本还得自己动手手上有个 legacy 系统要对接地理数据对方只认 GDAL 1.11.5 的接口行为新版本 3.x 的坐标轴顺序和部分驱动默认值都变了直接换版本会引发一连串回归问题。这时候最省事的路径不是改业务代码而是把 1.11.5 在 Windows 上重新编出来。mingw64 编译 GDAL 1.11.5 这件事本质是用一套 GNU 工具链在 Windows 上产出一个可用的地理数据处理库绕开 MSVC 的工程文件泥潭也绕开官方不再维护的旧版二进制包。适合谁看需要在 Windows 上跑老版本 GDAL 的 GIS 后端工程师、做遥感数据批处理但被版本锁死的人、以及想用 mingw64 统一管理 C/C 依赖的开发者。不适合完全没碰过命令行编译的人因为 GDAL 的依赖链在 Windows 上确实有点玄学。下面按“先立住原理、再动手复现、最后排坑”的顺序走每一步都给出可抄的命令和参数解释。2. 编译前的环境与依赖mingw64 工具链怎么选、依赖库从哪来2.1 mingw64 发行版选择与 PATH 隔离Windows 上的 mingw64 有好几个来源常见的是 MSYS2 里的 mingw-w64-x86_64 工具链以及独立打包的 w64devkit。我一般用 MSYS2因为它的包管理器能直接装依赖省去手动编 zlib、libpng 的时间。安装完 MSYS2 后必须从“MSYS2 MinGW 64-bit”这个快捷方式进入终端而不是默认的 MSYS 终端。区别在于前者 PATH 里是/mingw64/bin后者是/usr/bin混用会导致链接阶段找不到正确的.dll。验证工具链是否就位which gcc gcc --version which pkg-config如果gcc指向/mingw64/bin/gcc说明环境正确。pkg-config在 GDAL 1.11.5 的 configure 阶段用来探测依赖MSYS2 里通过pacman -S pkg-config安装。注意不要用 MSYS 自带的 pkg-config 去探测 mingw64 的库路径前缀不同会直接报找不到。2.2 GDAL 1.11.5 的依赖清单与安装命令GDAL 1.11.5 的核心依赖不算多但少了任何一个都会在 configure 阶段静默跳过对应驱动。最低限度需要zlib、libpng、libjpeg-turbo、libtiff、libgeotiff、proj、sqlite3。如果要做栅格计算还得加 libcurl 和 expat。用 MSYS2 的 pacman 一次性装齐pacman -S --needed \ mingw-w64-x86_64-zlib \ mingw-w64-x86_64-libpng \ mingw-w64-x86_64-libjpeg-turbo \ mingw-w64-x86_64-libtiff \ mingw-w64-x86_64-libgeotiff \ mingw-w64-x86_64-proj \ mingw-w64-x86_64-sqlite3 \ mingw-w64-x86_64-curl \ mingw-w64-x86_64-expat参数--needed表示已安装的包不重复下载。装完后用pkg-config --list-all | grep -E gdal|proj|tiff确认这些库的.pc文件都在/mingw64/lib/pkgconfig下。这里有个血泪经验MSYS2 滚动更新后 proj 可能升到 6.x 以上而 GDAL 1.11.5 只认 proj 4.x 的 API。如果pacman装出来的 proj 版本过高configure 会报proj_api.h not found。解决办法是从 MSYS2 的旧包缓存里找mingw-w64-x86_64-proj-4.9.3或者手动下载 proj 4.9.3 源码用同样的 mingw64 工具链编一份装到/mingw64下。2.3 源码获取与目录约定GDAL 1.11.5 的源码包在官方归档里还能找到文件名通常是gdal-1.11.5.tar.gz。下载后解压到一个不含空格和中文的路径比如D:/build/gdal-1.11.5。在 MSYS2 终端里用/d/build/gdal-1.11.5访问。不要放在C:/Program Files下configure 脚本对空格路径的处理很脆弱会在生成 Makefile 时把路径截断导致编译到一半报No rule to make target。目录结构确认cd /d/build/gdal-1.11.5 ls configure ls frmts/configure存在且frmts/下有gtiff、png等子目录说明源码完整。如果是从 git 仓库克隆的还需要先跑./autogen.sh生成 configure但 1.11.5 的发布包已经带好了不用多这一步。3. configure 与编译参数怎么设、驱动怎么裁3.1 configure 关键参数逐条说明GDAL 的 configure 脚本选项很多但针对 mingw64 编译 1.11.5真正影响成败的就那几个。下面是我常用的配置命令./configure \ --prefix/mingw64 \ --hostx86_64-w64-mingw32 \ --buildx86_64-w64-mingw32 \ --with-pnginternal \ --with-jpeginternal \ --with-libtiffinternal \ --with-geotiffinternal \ --with-proj/mingw64 \ --with-sqlite3/mingw64 \ --with-curl/mingw64 \ --without-python \ --without-java \ --without-perl \ --disable-shared \ --enable-static逐条解释--prefix/mingw64让安装结果直接进 MSYS2 的 mingw64 前缀后续其他项目用pkg-config就能找到。--host和--build都设成x86_64-w64-mingw32避免 configure 误判为交叉编译而跳过某些检测。--with-pnginternal这类 internal 选项表示用 GDAL 源码树里自带的库好处是版本可控坏处是编译时间变长。如果你已经用 pacman 装了外部库也可以改成--with-png/mingw64但要注意头文件路径是否匹配。--without-python和--without-java是必须的因为 1.11.5 的 Python 绑定只支持 Python 2.x在现在的环境里基本编不过强行开启只会浪费时间。--disable-shared --enable-static生成静态库方便后续链接进独立 exe如果你需要.dll把这两行换成--enable-shared --disable-static。configure 跑完后重点看输出末尾的摘要GEOS support: no PROJ.4 support: yes PNG support: yes JPEG support: yes TIFF support: yes如果 PROJ.4 显示 no说明 proj 的路径没被正确识别检查/mingw64/include/proj_api.h是否存在。如果 PNG 显示 no多半是 zlib 没找到用pkg-config --cflags zlib看输出是否为空。3.2 编译与安装并行度、错误定位configure 成功后用 make 编译。GDAL 1.11.5 的代码量不小单线程编要十几分钟用-j加速make -j$(nproc) 21 | tee build.log$(nproc)在 MSYS2 里返回 CPU 核心数。tee build.log把输出同时写到文件方便出错后回看。如果编译中途报错先看最后 30 行tail -n 30 build.log常见的编译错误有两类一是头文件找不到比如fatal error: proj_api.h: No such file or directory说明--with-proj的路径不对二是类型冲突比如conflicting types for sqlite3_open通常是 sqlite3 头文件版本和链接库版本不一致用pacman -S mingw-w64-x86_64-sqlite3重装可解决。编译完成后安装make install安装到/mingw64下生成libgdal.a、gdal-config等文件。验证gdal-config --version输出1.11.5就说明安装成功。如果报command not found检查/mingw64/bin是否在 PATH 里。3.3 驱动裁剪只编你需要的格式GDAL 默认会尝试编译所有驱动但很多驱动依赖的库在 Windows 上并不好找。与其让 configure 静默跳过不如显式关掉不需要的减少编译时间和出错面。比如只做 GeoTIFF 和 PNG 读写可以加--without-grib \ --without-hdf4 \ --without-hdf5 \ --without-netcdf \ --without-pg \ --without-mysql \ --without-odbc \ --without-xml2这些选项在 configure 阶段就会跳过对应目录不会进入编译。注意--without-xml2会同时关掉 KML 和 GPX 驱动如果业务里要读 KML就别加这一条。裁剪的代价是功能变少好处是编译成功率大幅提升。我一般先全默认编一次记录哪些驱动报错再在第二次编译时针对性关掉。4. 避坑与排查mingw64 编译 GDAL 1.11.5 的五个翻车现场4.1 现象configure 报 “C compiler cannot create executables”原因MSYS2 的 mingw64 工具链没装全或者 PATH 里混入了 MSYS 的 gcc。MSYS 的 gcc 生成的是依赖msys-2.0.dll的可执行文件而 mingw64 的 gcc 生成的是原生 Windows 可执行文件两者混用会导致链接阶段找不到入口。解决确认which gcc输出/mingw64/bin/gcc。如果不是检查是否从“MSYS2 MinGW 64-bit”快捷方式进入。如果已经进入但 PATH 仍不对手动export PATH/mingw64/bin:$PATH再试。4.2 现象编译到ogr/ogrsf_frmts/sqlite时报undefined reference to sqlite3_column_table_name原因GDAL 1.11.5 的 SQLite 驱动用到了sqlite3_column_table_name这个函数它只在 SQLite 的SQLITE_ENABLE_COLUMN_METADATA编译选项开启时才存在。MSYS2 预编译的 sqlite3 默认没开这个选项。解决要么自己编一份带-DSQLITE_ENABLE_COLUMN_METADATA的 sqlite3要么在 configure 时加--without-sqlite3关掉 SQLite 驱动。如果业务不需要 SQLite 格式关掉最省事。4.3 现象make install后gdal-config --version输出为空原因gdal-config脚本里的prefix变量在安装时被写成了 configure 时的相对路径而 MSYS2 的路径转换机制在安装阶段把/mingw64转成了D:/msys64/mingw64导致脚本里的路径和实际不符。解决用文本编辑器打开/mingw64/bin/gdal-config把prefix那一行改成prefix/mingw64保存后再执行。这是 MSYS2 下编译 autotools 项目的常见问题不是 GDAL 独有的。4.4 现象链接静态库时提示undefined reference to png_create_read_struct原因--with-pnginternal虽然把 libpng 编进了 GDAL但生成的libgdal.a并不会自动把 libpng 的目标文件合并进去。链接你的程序时需要额外指定-lpng -lz。解决用gdal-config --libs看它输出的链接参数如果缺少-lpng手动补上。或者改用--with-png/mingw64链接外部 libpng这样gdal-config --libs会自动带上-lpng。4.5 现象编译过程中内存占用飙升最后被系统杀掉原因GDAL 1.11.5 的某些源文件比如gdal_priv.cpp非常大mingw64 的 gcc 在优化阶段会消耗大量内存。如果make -j的并行度设得太高多个大文件同时编译32 位进程很容易撞到 2GB 内存上限。解决降低并行度用make -j2甚至make -j1。如果还是不够在 configure 时加CXXFLAGS-O1降低优化等级牺牲一点运行速度换编译稳定性。5. 验证与进阶用编译产物跑通一次 GeoTIFF 读写5.1 写一个最小验证程序编译出来的库到底能不能用写个十几行的 C 程序测一下最直接。下面这段代码创建一个内存中的 GeoTIFF 数据集写入一个像素再读回来#include gdal_priv.h #include cpl_conv.h int main() { GDALAllRegister(); // 注册所有驱动 GDALDriver *drv GetGDALDriverManager()-GetDriverByName(GTiff); if (drv NULL) { printf(GTiff driver not found\n); return 1; } // 创建 1x1 的 Byte 数据集 GDALDataset *ds drv-Create(/vsimem/test.tif, 1, 1, 1, GDT_Byte, NULL); if (ds NULL) { printf(Create failed\n); return 1; } // 写入像素值 42 GByte val 42; ds-GetRasterBand(1)-RasterIO(GF_Write, 0, 0, 1, 1, val, 1, 1, GDT_Byte, 0, 0); // 读回 GByte out 0; ds-GetRasterBand(1)-RasterIO(GF_Read, 0, 0, 1, 1, out, 1, 1, GDT_Byte, 0, 0); printf(read back: %d\n, out); GDALClose(ds); return 0; }编译命令g -o test_gdal test_gdal.cpp $(gdal-config --cflags) $(gdal-config --libs) -lz -lpnggdal-config --cflags给出头文件路径--libs给出链接库列表。如果链接报错按第 4 章的排查思路补-l参数。运行./test_gdal输出read back: 42就说明 GeoTIFF 驱动工作正常。5.2 用 gdalinfo 检查驱动列表编译产物里带了一个gdalinfo工具直接跑gdalinfo --formats | head -n 20这会列出所有已编译进去的驱动。如果发现某个格式不在列表里回到 configure 阶段检查对应依赖是否被正确探测。比如GTiff不在说明 libtiff 或 libgeotiff 没找到PNG不在说明 zlib 或 libpng 有问题。5.3 静态库链接进独立 exe 的注意事项如果你要把libgdal.a链接进一个独立 exe 发给别人需要确保所有依赖的静态库都链进去。用gdal-config --dep-libs看 GDAL 自己记录的依赖列表然后逐个补上。mingw64 下常见的坑是-lstdc和-lwinpthread的顺序放在-lgdal后面才能正确解析符号。一个可用的链接命令模板g -o myapp myapp.cpp -static \ -I/mingw64/include \ -L/mingw64/lib \ -lgdal -ltiff -lgeotiff -lpng -ljpeg -lz -lproj -lsqlite3 -lcurl -lexpat \ -lstdc -lwinpthread -lws2_32 -lcrypt32-static表示静态链接生成的 exe 不依赖 mingw64 的 dll。-lws2_32和-lcrypt32是 Windows 系统库curl 和 sqlite3 会用到。链接顺序很重要被依赖的库放在后面否则会报undefined reference。5.4 一个我常犯的错误每次重新编译 GDAL 后我总忘记清理之前链接过旧版libgdal.a的中间文件导致新库的符号和旧目标文件混在一起报一些莫名其妙的multiple definition。后来养成的习惯是make install之后先make clean清掉 GDAL 自己的目标文件再在业务项目里执行一次全量重建。这个习惯帮我省下了至少两次通宵排查的时间。希望帮到你。本文还有配套的精品资源点击获取
