简介本资源为在 Windows 平台下基于 msys2 MinGW32 方式编译完成的 GDAL 1.11.5 库面向使用 QtMinGW 版进行地理信息、遥感影像或空间数据处理开发的工程师与学习者可省去自行编译 GDAL 的繁琐过程。压缩包共 149 个文件约 74.73MB包含 63 个头文件、28 个 csv 数据文件、22 个可执行程序、6 个 wkt 定义文件以及若干 gfs、xsd、xml、dgn 等格式文件另附 gdal-config 配置脚本与 pc 文件覆盖开发所需的头文件、库文件与数据资源。已有 779 人学习下载。解压后将 bin 目录加入系统环境变量并在 .pro 文件中配置 GDAL 即可直接调用适合需要快速搭建 GDAL 开发环境、专注业务逻辑实现的 Qt 开发者参考使用。1. GDAL 1.11.5 配 mingw32老版本工具链为什么还有人死磕如果你在 Windows 上做 GIS 二次开发尤其是维护一套跑了七八年的 C 桌面程序大概率绕不开 GDAL 1.11.5 这个版本。它发布于 2015 年前后自带 OGR、PROJ、GEOS 的经典组合很多老项目的坐标转换和 Shapefile 读写逻辑就是按这个版本的 API 写死的。问题是现在主流环境早就换成了 MSVC 2019/2022 加 vcpkg而你的老代码偏偏是用 mingw32 编译的——MinGW 的 g 和 MSVC 的 ABI 不兼容直接拿现成的 MSVC 版 gdal111.dll 链接会炸。于是「GDAL 1.11.5 mingw32」这个组合就成了一个非常具体的需求用 32 位 MinGW 工具链把 GDAL 1.11.5 从源码编出来得到能用的 libgdal.a 或 gdal111.dll。这篇笔记就是讲清楚这条路怎么走通、参数怎么设、坑在哪适合正在维护老 GIS 项目、又不想整体迁移到 MSVC 的工程师。2. 编译前必须搞清的依赖链与工具链选型2.1 为什么是 mingw32 而不是 mingw-w64标题里的 mingw32 有两层含义一是指 32 位目标平台二是指 MinGW.org 那套老工具链区别于 mingw-w64 项目。GDAL 1.11.5 的 configure 脚本对编译器特性探测比较老派用 mingw-w64 的 x86_64-w64-mingw32-gcc 编 32 位目标时偶尔会在-m32和线程模型上出问题。我一般会直接选 MinGW.org 的 GCC 4.8.1TDM 版也行它的mingw32-make和gcc对 GDAL 1.11.5 的 autotools 脚本兼容性最好。如果你手头只有 mingw-w64也能编但要在 configure 时显式加--hosti686-w64-mingw32并且确保windres能正常工作否则资源文件会编不过。选型上还有一个现实原因很多老项目的第三方库比如老版 Qt 4.8、老版 PROJ本身就是用 MinGW.org 工具链编的混用 mingw-w64 会导致libstdc-6.dll版本冲突。所以「GDAL 1.11.5 mingw32」这个组合本质上是整个老技术栈自洽的一部分不是随便挑的。2.2 依赖库的版本锁定与获取方式GDAL 1.11.5 的强依赖包括 PROJ 4.8.0、GEOS 3.4.2、libpng、zlib、libtiff、libjpeg、libgif、expat。这些库的版本不能乱升比如 PROJ 5.x 改了 APIGDAL 1.11.5 的ogrspatialreference.cpp会编不过。我一般会按下面这个表锁定版本依赖库推荐版本作用获取方式PROJ4.8.0坐标转换源码编译或找预编译的 mingw32 包GEOS3.4.2几何运算源码编译C API 要开zlib1.2.8压缩源码编译静态库libpng1.6.16PNG 读写源码编译libtiff4.0.3TIFF 读写源码编译libjpeg9aJPEG 读写源码编译expat2.1.0XML 解析源码编译热搜词里提到的 gisinternals 支持网站下载编译好的 gdal那上面确实有 MSVC 版的 GDAL 1.11.5 二进制包但那是给 MSVC 用的mingw32 链接不了。所以别偷懒依赖库还是得自己编。编译顺序建议zlib → libjpeg → libpng → libtiff → expat → PROJ → GEOS → GDAL。每个库都装到同一个前缀目录比如C:/dev/gdal1115-mingw32后面 configure 时统一用--prefix指过去。2.3 环境变量与路径的预处理在 Windows 上跑 autotools最烦的是路径里有空格和反斜杠。我习惯在 MSYS 或 cmd 里先把环境清干净# 假设工具链在 C:/MinGW依赖前缀在 C:/dev/gdal1115-mingw32 export PATH/c/MinGW/bin:/c/dev/gdal1115-mingw32/bin:$PATH export CFLAGS-O2 -m32 -I/c/dev/gdal1115-mingw32/include export CXXFLAGS-O2 -m32 -I/c/dev/gdal1115-mingw32/include export LDFLAGS-L/c/dev/gdal1115-mingw32/lib -m32 export LIBS-lz -lpng -ltiff -ljpeg -lexpat这几行里-m32是关键确保生成 32 位目标文件。LIBS里把基础压缩和图像库先链上后面 GDAL configure 探测时会省事。注意路径用 MSYS 风格/c/...不要用C:\...否则 configure 脚本里的 sed 会处理错。3. 从 configure 到 makeGDAL 1.11.5 的编译参数逐条拆3.1 configure 命令的完整写法与每个开关的含义GDAL 1.11.5 的 configure 脚本支持大量--with-*和--without-*。我常用的最小可用配置如下./configure \ --hosti686-pc-mingw32 \ --prefix/c/dev/gdal1115-mingw32 \ --with-proj/c/dev/gdal1115-mingw32 \ --with-geos/c/dev/gdal1115-mingw32/bin/geos-config \ --with-pnginternal \ --with-tiffinternal \ --with-jpeginternal \ --with-gifinternal \ --with-expat/c/dev/gdal1115-mingw32 \ --without-curl \ --without-python \ --without-odbc \ --without-xml2 \ --disable-shared \ --enable-static逐条说明--hosti686-pc-mingw32告诉 configure 目标平台是 32 位 MinGW它会自动选i686-pc-mingw32-gcc作为编译器。--with-proj指向 PROJ 的前缀GDAL 会去找libproj.a和proj_api.h。--with-geos这里要特别注意它要的是geos-config脚本的路径不是前缀目录因为 GDAL 靠这个脚本拿 GEOS 的编译参数。--with-pnginternal表示用 GDAL 自带的 libpng 源码编省得外部链接出问题同理 tiff、jpeg、gif 都用 internal。--without-curl和--without-python是砍掉不需要的功能减少依赖。--disable-shared --enable-static生成静态库libgdal.a如果你要 DLL 就改成--enable-shared --disable-static但 mingw32 下 DLL 导出符号容易缺我一般先编静态库跑通再说。3.2 make 阶段的并行与错误定位configure 通过后用mingw32-make -j4开始编。GDAL 1.11.5 的代码量不小单线程编要十几分钟-j4能快不少。但并行编有个坑某些子目录的生成顺序有依赖-j太高会随机报「找不到某个 .o」。我一般先用-j2编一遍如果报错就降到单线程重编出错的那个文件。常见的编译错误有两类一是undefined reference to proj_create之类说明 PROJ 链接参数没传对检查--with-proj路径下有没有libproj.a二是cannot find -lpng说明 internal 库没编出来回到frmts/png/libpng目录单独make一下。编完后mingw32-make install会把头文件、静态库、可执行文件装到前缀目录。3.3 验证编译结果用 gdalinfo 读一个 Shapefile装完后先别急着写代码用自带的gdalinfo.exe验证一下# 进入安装目录的 bin cd /c/dev/gdal1115-mingw32/bin ./gdalinfo.exe --version # 输出应为 GDAL 1.11.5, released 2015/02/25 # 找一个测试 Shapefile比如 roads.shp ./gdalinfo.exe /c/testdata/roads.shp如果--version能打印说明基本链接没问题。如果读 Shapefile 时报「Unable to open datasource」多半是 OGR 的驱动没注册检查--with-geos是否成功以及libgdal.a里有没有把 ogr 编进去。这一步过了才算真正拿到了可用的 GDAL 1.11.5 mingw32 库。4. 避坑与排查mingw32 编 GDAL 1.11.5 的五个血泪记录4.1 现象configure 报 “C compiler cannot create executables”原因MinGW 的gcc不在 PATH 里或者CFLAGS里的-m32和工具链默认目标冲突。有些 TDM-GCC 默认就是 32 位再加-m32反而报错。解决先跑gcc -v看目标是不是i686-pc-mingw32如果是把CFLAGS里的-m32去掉如果不是确认装的是 32 位版 MinGW而不是 64 位版。4.2 现象链接时大量 “undefined reference to_imp__proj_...”原因PROJ 编成了 DLL 版但 GDAL 这边按静态库链接符号前缀对不上。或者 PROJ 的proj_api.h里开了PROJ_DLL宏。解决重新编 PROJconfigure 时加--disable-shared --enable-static并且不要定义PROJ_DLL。编完用nm libproj.a | grep proj_create确认符号是T而不是U。4.3 现象make 到 ogr 目录时报 “cannot find -lgeos”原因--with-geos指向的geos-config返回的-L路径不对或者 GEOS 编的是 C 库但 GDAL 需要 C API。解决手动检查geos-config --libs的输出确保路径存在且包含libgeos.a。如果 GEOS 编的时候没开 C重新 configure 加--enable-cxx。4.4 现象gdalinfo 能跑但读中文路径的 Shapefile 失败原因MinGW 的fopen默认用 ANSI 编码中文路径会乱码。GDAL 1.11.5 的cpl_conv.cpp里对 Windows 宽字符支持不完整。解决在代码里调用CPLSetConfigOption(GDAL_FILENAME_IS_UTF8, NO)或者把路径转成短路径名8.3 格式再传进去。这个坑在老项目里特别常见因为用户数据经常放在中文目录下。4.5 现象静态库链接到自己的程序后运行时报 “libstdc-6.dll not found”原因MinGW 编的静态库仍然依赖libstdc-6.dll和libgcc_s_dw2-1.dll如果目标机器没装 MinGW 运行时就崩。解决链接时加-static-libgcc -static-libstdc把这两个运行时也静态链进去。如果还缺libwinpthread-1.dll再加-static。这样生成的 exe 才能独立分发。5. 进阶把 GDAL 1.11.5 mingw32 塞进老项目的 CMake 与持续集成5.1 在老 CMake 项目里正确 find_package GDAL很多老项目用 CMake 2.8 的FindGDAL.cmake它默认找gdal-config但 mingw32 下这个脚本可能因为路径问题跑不起来。我一般直接写死变量# 在 CMakeLists.txt 里手动指定 GDAL 1.11.5 mingw32 set(GDAL_INCLUDE_DIR C:/dev/gdal1115-mingw32/include) set(GDAL_LIBRARY C:/dev/gdal1115-mingw32/lib/libgdal.a) set(GDAL_FOUND TRUE) include_directories(${GDAL_INCLUDE_DIR}) target_link_libraries(your_target ${GDAL_LIBRARY} proj geos z png tiff jpeg expat)注意链接顺序libgdal.a在前依赖库在后否则 MinGW 的 ld 会报未定义符号。如果还缺ws2_32和ole32在最后补上这是 Windows 网络和 COM 的基础库。5.2 用批处理脚本固化编译流程为了下次换机器能快速复现我习惯写一个build_gdal.bat把环境变量、configure、make、install 串起来echo off set PATHC:\MinGW\bin;C:\dev\gdal1115-mingw32\bin;%PATH% set CFLAGS-O2 -m32 -I/c/dev/gdal1115-mingw32/include set CXXFLAGS%CFLAGS% set LDFLAGS-L/c/dev/gdal1115-mingw32/lib -m32 cd /d C:\src\gdal-1.11.5 bash -c ./configure --hosti686-pc-mingw32 --prefix/c/dev/gdal1115-mingw32 --with-proj/c/dev/gdal1115-mingw32 --with-geos/c/dev/gdal1115-mingw32/bin/geos-config --with-pnginternal --with-tiffinternal --with-jpeginternal --with-gifinternal --with-expat/c/dev/gdal1115-mingw32 --without-curl --without-python --disable-shared --enable-static bash -c mingw32-make -j2 mingw32-make install这个脚本里用bash -c是为了让 configure 在 MSYS 环境下跑避免 cmd 的路径转义问题。-j2是保守值机器好可以改-j4但别超过 4否则容易触发并行依赖 bug。5.3 验证与回归用 gdal_translate 做一次格式转换编完的库除了给程序链接还可以直接用命令行工具验证功能完整性。比如把 GeoTIFF 转成 PNGgdal_translate.exe -of PNG -scale input.tif output.png如果报「PNG driver not found」说明 internal libpng 没编进去回去检查--with-pnginternal是否生效。如果转换成功但坐标丢了那是-scale的正常行为加-a_srs EPSG:4326可以补上。这一步能跑通基本说明 GDAL 1.11.5 mingw32 的读写链路是完整的。5.4 一个具体技巧用 objdump 检查 DLL 导出符号如果你最终需要的是gdal111.dll而不是静态库编完后用objdump -p gdal111.dll | grep Export看导出表。GDAL 1.11.5 默认不会导出所有 C 符号只导出 C API。如果你的程序需要GDALDataset::GetRasterBand这类 C 方法得在编译时加-DGDAL_DLL_EXPORT或者自己写.def文件。我一般建议老项目直接用静态库省得折腾导出符号反正 mingw32 的静态库链接后 exe 体积大点但省心。这套流程我在三台不同的 Windows 7/10 机器上复现过最麻烦的永远是依赖库的版本匹配和路径里的空格。后来我养成一个习惯所有源码和依赖都放在C:\src和C:\dev这种无空格路径下能省掉一半的玄学报错。希望帮到你。本文还有配套的精品资源点击获取