简介本资源是作者在 Windows 下用 msys2 mingw64 方式预先编译好的 GDAL 1.11.5 库面向使用 QtMinGW 版进行 C 地理信息开发的工程师与学习者解决自行编译 GDAL 耗时长、依赖配置繁琐的问题。压缩包共 149 个文件约 70.71MB包含 63 个 h 头文件、22 个 exe 工具、28 个 csv 坐标与投影数据、8 个 gfs、6 个 wkt 及 a、dll、pc 等库与配置相关文件覆盖开发所需的头文件、静态与动态库、命令行工具及数据字典。下载解压后把 bin 目录加入系统环境变量并在 .pro 中配置即可直接调用。目前已有 1516 人学习下载适合需要快速搭建 GDAL 开发环境、避免重复编译的 Qt 开发者参考使用。1. 为什么今天还有人要在 mingw64 下编译 GDAL 1.11.5手里维护着一套老 GIS 桌面工具依赖链锁死在 GDAL 1.11.5 这个版本上升级一次就要重测几十个栅格处理流程这种场景下你大概率会碰到和我一样的问题Windows 上现成的二进制包要么是 MSVC 编译的和项目里 mingw64 工具链的 ABI 对不上要么版本太新接口签名已经变了。mingw64 编译 GDAL 1.11.5 这件事本质上不是「怀旧」而是给一条已经跑通的老链路补一个能自洽的构建环节。GDAL 1.11.5 属于 1.x 末期版本自带configure脚本没有后来 CMake 那套东西对 mingw64 的兼容性其实比想象中好坑主要集中在依赖库的探测和gdal1115.dll的导出符号上。这篇笔记面向两类人一类是被老项目绑住、必须自己出 DLL 的维护者另一类是刚接触 mingw64想拿一个真实的中型 C/C 库练手交叉编译的工程师。下面从环境准备一路写到验证和进阶技巧参数、命令、报错都按我实际跑过的来。2. mingw64 工具链与 GDAL 1.11.5 的依赖清单2.1 为什么选 mingw64 而不是 MSVC先说选型。GDAL 1.11.5 那个年代官方 Windows 构建基本走 MSVC但 MSVC 的运行时MSVCR和 mingw64 默认的 msvcrt/UCRT 是两套东西。如果你的主程序是 mingw64 编出来的链接 MSVC 版 GDAL 时经常在std::string跨 DLL 传递、FILE*归属上翻车表现为运行期随机崩溃而不是链接报错这种玄学问题排查起来非常费时间。mingw64 的好处是工具链统一主程序、GDAL、依赖库全部用同一套 gccC ABI 一致异常和 STL 对象跨模块传递不会出问题。代价是你要自己把 GDAL 依赖的那一堆第三方库也编出来或者找到 mingw64 能直接用的预编译包。我一般会先确认工具链位数和线程模型这一步错了后面全白干。# 确认 mingw64 版本、目标架构和线程模型 gcc -v # 关注输出里的 Target: x86_64-w64-mingw32 # 以及 Thread model: posixGDAL 依赖的 pthread 需要 posix 线程模型 # 确认 make 和 pkg-config 可用 make --version pkg-config --version逻辑说明gcc -v里的Target决定你编出来的是 64 位还是 32 位必须和主程序一致Thread model如果是win32后面编译依赖 pthread 的库会失败需要换 posix 版本的 mingw64。参数上没什么可调的这一步纯粹是体检。2.2 GDAL 1.11.5 的最小依赖集GDAL 1.11.5 的configure支持大量可选驱动全开会让依赖地狱直接爆炸。做最小可用构建我一般只保留 GeoTIFF、PNG、JPEG 和 Shapefile 这几类对应的依赖是 zlib、libtiff、libjpeg、libpng、proj。proj 负责投影变换如果你只做栅格读写可以暂时不带但一旦涉及坐标转换就必须有。依赖库作用是否必须mingw64 下的注意点zlib压缩tiff/png 都依赖必须版本别太新1.2.8 附近最稳libtiffGeoTIFF 读写必须要关掉 lzma、jbig 等可选压缩libjpegJPEG 驱动建议用 jpeg-9 之前的版本libpngPNG 驱动建议依赖 zlib先编 zlibproj投影变换按需4.x 系列和 GDAL 1.11 匹配依赖的编译顺序是 zlib → libjpeg → libpng → libtiff → proj → GDAL顺序错了会出现「找不到符号」或者「头文件版本不匹配」。每个依赖都用同样的--prefix装到一个统一目录比如/mingw64/local这样 GDAL 配置时一个--with-指过去就行不用满世界找路径。2.3 把依赖装进统一前缀以 zlib 为例展示一个依赖的标准编法其余库套路一致只是configure参数不同。# 以 zlib 为例安装到统一前缀 ./configure --prefix/mingw64/local make -j4 make install # libtiff 配置时显式关掉不需要的压缩后端减少依赖 ./configure --prefix/mingw64/local \ --disable-lzma --disable-jbig --disable-zstd \ --with-jpeg-include-dir/mingw64/local/include \ --with-jpeg-lib-dir/mingw64/local/lib make -j4 make install逻辑说明--prefix统一到/mingw64/local是为了让 GDAL 的configure能通过CPPFLAGS/LDFLAGS一次性找到所有依赖。--disable-lzma这类开关很关键libtiff 默认会去探测系统里的 lzma探测到了就要求你链接探测不到又可能编出半残的库显式关掉最省心。参数上-j4按你 CPU 核数调整老机器用-j2避免内存爆掉。3. 配置 GDAL 1.11.5configure 参数逐个拆3.1 环境变量先摆正GDAL 1.11.5 的configure是 autotools 生成的它找依赖靠的是CPPFLAGS、LDFLAGS和PKG_CONFIG_PATH。mingw64 下最容易犯的错是路径用了 Windows 反斜杠或者盘符autotools 不认。统一用 MSYS2 风格的/mingw64/...路径。# 把依赖的头文件和库路径暴露给 configure export CPPFLAGS-I/mingw64/local/include export LDFLAGS-L/mingw64/local/lib export PKG_CONFIG_PATH/mingw64/local/lib/pkgconfig export PATH/mingw64/local/bin:$PATH # 验证 pkg-config 能否找到依赖 pkg-config --cflags --libs libtiff-4逻辑说明CPPFLAGS管编译期头文件搜索LDFLAGS管链接期库搜索PKG_CONFIG_PATH让configure通过 pkg-config 拿到精确的编译链接参数。最后那条pkg-config是自检如果报「Package libtiff-4 was not found」说明 libtiff 没装到前缀里或者.pc文件路径不对先解决这个再往下走。3.2 configure 命令与关键开关GDAL 1.11.5 的configure开关很多全开不现实。下面这条是我验证过能出 DLL 的最小配置保留了常用栅格和矢量驱动。./configure --prefix/mingw64/local \ --hostx86_64-w64-mingw32 \ --with-libtiff/mingw64/local \ --with-libz/mingw64/local \ --with-png/mingw64/local \ --with-jpeg/mingw64/local \ --with-proj/mingw64/local \ --without-python \ --without-curl \ --without-geos \ --disable-shared --enable-static逻辑说明--host明确告诉 autotools 这是交叉编译目标mingw64 下即使你在 MSYS2 里本地编也要带上否则它可能按 Linux 规则探测。--with-xxx指定依赖前缀比依赖环境变量更精确。--without-python一定要加GDAL 1.11.5 的 Python 绑定在 mingw64 下基本编不过而且你多半也不需要。--disable-shared --enable-static先出静态库静态库能过再开动态库分两步排查问题。提示如果你确实需要gdal1115.dll把最后一行改成--enable-shared --disable-static但动态库导出符号的问题会在第 5 章单独讲。3.3 configure 输出怎么读configure跑完会打印一张依赖汇总表重点看三处Libtiff support、PROJ.4 support、JPEG support是不是yes。如果某个是no往上翻日志找checking for ...那几行通常能看到具体原因比如头文件找不到或者库链接失败。# 把 configure 输出存下来方便回查 ./configure ... 21 | tee configure.log # 只看关键依赖的探测结果 grep -E Libtiff support|PROJ|JPEG support|PNG support configure.log逻辑说明tee同时输出到屏幕和文件configure 日志很长出问题时回查比重新跑一遍快。grep过滤出关键行一眼就能判断依赖是否齐全。这一步不通过就别急着make否则编译到一半报错更难看。4. 编译、链接与产物验证4.1 make 阶段的常见中断configure通过后make -j4一般能跑很久。GDAL 1.11.5 代码量不小中途中断大多集中在几个老驱动的源码上比如某些格式的解析代码用了较新的 C 特性或者和 mingw64 的头文件有冲突。# 编译保留详细输出 make -j4 21 | tee build.log # 如果中断定位到具体文件 grep -n error: build.log | head -20逻辑说明-j4并行编译提速但报错信息会交错所以配合tee存日志。grep error:能快速定位第一个真正的错误注意有些error是级联的修掉第一个往往后面一片都好了。mingw64 下常见的错误是undefined reference to xxx这通常是某个依赖没链上回到configure检查对应--with-开关。4.2 静态库与动态库的产物差异编译完成后--enable-static会在.libs目录下生成libgdal.a--enable-shared会生成libgdal.dll.a导入库和gdal1115.dll运行时。静态库链接进主程序后不依赖外部 DLL部署简单但体积大动态库部署时要带上 DLL 和它依赖的一串第三方 DLL。产物文件名用途部署要求静态库libgdal.a直接链进主程序无外部依赖导入库libgdal.dll.a链接动态库时用需配合 DLL运行时gdal1115.dll动态库本体需带齐依赖 DLL我一般先出静态库验证功能确认没问题再切动态库。静态库能过说明代码和依赖都对动态库再出问题就纯粹是导出符号和运行时加载的事排查范围小很多。4.3 用 gdalinfo 验证构建结果产物出来后最直接的验证是编一个gdalinfo或者用自带的工具跑一张测试影像。GDAL 1.11.5 源码里带了apps/gdalinfo.c编出来的可执行文件能读影像就说明核心链路通了。# 编译自带的 gdalinfo 工具 cd apps make gdalinfo # 用一张测试 tif 验证 ./gdalinfo.exe test.tif # 期望输出包含 Driver: GTiff/GeoTIFF 和影像尺寸、坐标系信息逻辑说明gdalinfo是最小验证工具它走的是 GDAL 的驱动注册和栅格读取全流程。如果它能正确打印出Driver、Size is、Coordinate System说明 GeoTIFF 驱动、投影库、压缩库都链接正常。参数上test.tif随便找一张带地理信息的影像即可没有的话用gdal_translate从别的格式转一张。注意如果gdalinfo报「Unable to open datasource」先确认GDAL_DATA环境变量指向了源码里的data目录GDAL 1.11.5 的坐标轴定义和投影参数都放在那里。5. 避坑与排查mingw64 编译 GDAL 1.11.5 的五个血泪记录5.1 现象链接时报undefined reference to _imp__...原因这是 mingw64 下动态库导出符号的经典问题。GDAL 1.11.5 的源码里有些函数没有加__declspec(dllexport)编动态库时符号没导出主程序链接导入库时就找不到。静态库不会有这个问题因为符号直接进目标文件。解决优先用静态库。如果必须用动态库检查gdal的port目录下cpl_port.h里的CPL_DLL宏定义确保GDAL_DLL在编译动态库时被正确定义为__declspec(dllexport)。实在不行用--export-all-symbols链接选项强制导出但会导出大量内部符号不推荐。5.2 现象configure 报checking for proj... no原因proj 4.x 的 pkg-config 文件名可能是proj.pc而不是proj-4.pcGDAL 1.11.5 的探测脚本按老名字找找不到就判定为 no。或者 proj 装到了非标准前缀PKG_CONFIG_PATH没覆盖到。解决确认/mingw64/local/lib/pkgconfig/下有proj.pc没有的话手动写一个内容指向 proj 的头文件和库。然后export PKG_CONFIG_PATH包含该目录重新configure。如果还不行用--with-proj/mingw64/local显式指定绕过 pkg-config。5.3 现象编译到ogr模块时内存耗尽或卡死原因make -j并行度太高GDAL 1.11.5 的某些 OGR 驱动源码文件巨大单个文件编译就吃几百 MB 内存多文件并行直接把内存打满系统开始交换表现为卡死。解决降低并行度make -j2甚至make -j1。老机器上我一般直接-j1慢是慢点但稳。如果只是个别文件大可以先make -j4跑到卡住然后make -j1续上make 会跳过已完成的文件。5.4 现象运行时报The procedure entry point ... could not be located原因动态库版本冲突。你编的gdal1115.dll依赖某个第三方 DLL但系统 PATH 里有一个同名但不同版本的 DLL 被优先加载了比如 zlib1.dll 版本对不上。解决用objdump -p gdal1115.dll | grep DLL Name列出所有依赖 DLL逐个确认版本。部署时把依赖 DLL 和gdal1115.dll放同一目录并且确保该目录在 PATH 最前面。更彻底的办法是静态链接所有依赖只留一个gdal1115.dll但配置会复杂一些。5.5 现象gdalinfo能跑但读某些 tif 报错原因libtiff 编译时关掉了某些压缩后端而测试影像恰好用了那种压缩。比如你--disable-lzma遇到 LZMA 压缩的 tif 就报「compression not supported」。解决确认测试影像的压缩方式用gdalinfo看Compression字段。如果确实需要某种压缩重新编 libtiff 时打开对应开关再重编 GDAL。这也是为什么依赖编译顺序和开关要一次定好改一个依赖就要重编整条链。6. 进阶把构建固化成脚本与版本共存技巧6.1 用脚本固化整条构建链手工敲命令编一遍可以但要重复构建就必须脚本化。我一般写一个build_all.sh把依赖和 GDAL 的配置、编译、安装串起来每个库的版本和开关都写死避免下次手滑改了参数。#!/bin/bash # build_all.sh - mingw64 下构建 GDAL 1.11.5 及依赖 set -e # 任何一步失败立即退出 PREFIX/mingw64/local export CPPFLAGS-I$PREFIX/include export LDFLAGS-L$PREFIX/lib export PKG_CONFIG_PATH$PREFIX/lib/pkgconfig build_zlib() { cd zlib-1.2.8 ./configure --prefix$PREFIX make -j2 make install cd .. } build_libtiff() { cd tiff-4.0.6 ./configure --prefix$PREFIX --disable-lzma --disable-jbig make -j2 make install cd .. } build_gdal() { cd gdal-1.11.5 ./configure --prefix$PREFIX --hostx86_64-w64-mingw32 \ --with-libtiff$PREFIX --with-libz$PREFIX \ --with-png$PREFIX --with-jpeg$PREFIX \ --without-python --disable-shared --enable-static make -j2 make install cd .. } build_zlib build_libtiff build_gdal echo build done逻辑说明set -e保证任何一步失败就停不会带着半成品往下走。每个build_xxx函数封装一个库的完整流程版本号写死在目录名里。-j2是保守值机器好可以调高。这个脚本跑通一次后换机器只要改PREFIX就能复用。6.2 多版本 GDAL 共存的目录布局实际项目里经常要同时维护 GDAL 1.11.5 和更新的版本如果都装到/mingw64/local会互相覆盖。我的做法是按版本分目录用环境变量切换。版本安装前缀切换方式1.11.5/mingw64/gdal-1.11.5改 PATH 和 PKG_CONFIG_PATH3.x/mingw64/gdal-3.x同上切换时把对应前缀的bin加到 PATH 最前lib/pkgconfig加到 PKG_CONFIG_PATH 最前编译主程序时就会用对应版本。注意gdal1115.dll和 3.x 的 DLL 名字不同运行时不会冲突但依赖的第三方 DLL 如果版本不同要各自带齐。6.3 一个验证构建是否可复现的小技巧构建脚本最怕的是「这次能过下次不能过」通常是某个依赖的探测结果不稳定。我的习惯是每次构建后记录一份指纹把configure.log里的依赖汇总、gdalinfo --version的输出、以及objdump -p gdal1115.dll的依赖列表存到一个文本文件和构建脚本一起提交。下次构建结果对不上直接 diff 指纹文件一眼就能看出是哪个依赖变了。# 生成构建指纹 { echo gdal version ./apps/gdalinfo.exe --version echo dll deps objdump -p .libs/gdal1115.dll | grep DLL Name echo configure summary grep -E support configure.log } build_fingerprint.txt逻辑说明gdalinfo --version确认版本和编译时间objdump列出运行时依赖configure汇总确认驱动开关。三样合起来基本能唯一标识一次构建。指纹文件进版本库团队里谁构建结果不一致diff 一下就知道差异在哪。这套流程我前后在三四台机器上跑过最深的教训是依赖版本和 configure 开关一定要在第一次就定死并写进脚本靠记忆手敲迟早翻车。mingw64 编译 GDAL 1.11.5 本身不难难的是把这条老链路稳定复现出来一旦脚本化后面就是改改版本号的事。希望帮到你。本文还有配套的精品资源点击获取
