简介面向Windows下QtMinGW开发者的GDAL 1.11.5预编译包基于msys2MinGW64工具链构建省去自行搭建编译环境的成本适合在C工程中集成栅格/矢量读写能力的初中级开发者。压缩包共149个文件体积约70.71MB含63个C头文件、静态库、动态库及编译配置脚本均为Windows下可直接使用的编译产物22个exe为命令行工具集csv/wkt/gfs/xml等提供投影参数与要素样式信息。目前已有1519人学习下载。包内预置常用基准面与坐标转换数据、dxf/dgn矢量样例及svg辅助素材便于在QtMinGW环境下直接集成和验证GDAL功能。这些内容还能辅助理解投影转换与OGR驱动加载减少二次开发中的排错成本。1. 为什么要回头编译 GDAL 1.11.5一个老版本兼容性的硬骨头mingw64 编译 GDAL 1.11.5这个组合在今天看起来像考古。GDAL 已经迭代到 3.x新功能一大堆为什么还有人要找 2015 年的老版本我遇到的场景很典型某公司一套十年前的 GIS 支撑系统还在跑业务逻辑锁死了 GDAL 1.x 的 API 行为升级意味着重写几百处调用偏偏那台机器上的 MSVC 编译链早就断了新装的系统里只有 MinGW-w64 能用。这套流程就是给这类场景准备的用 MinGW-w64 在 Windows 上把 GDAL 1.11.5 完整编译出来连带处理 proj、GEOS 这些老依赖的版本匹配最后落到可执行文件能跑、能被自己的 C 工程链接。适合正在维护老代码或者被旧项目绑定在特定 GDAL 版本上的开发者读。2. 编译前的选型与准备MinGW-w64 版本、依赖链和工作目录规划2.1 为什么是 MinGW-w64 而不是 MSVC 或 Cygwin先讲清楚一个前提编译 GDAL 1.11.5 本身不难难的是编译出来之后给谁用。如果你的下游工程是 Visual Studio 编译的那直接去找 MSVC 版预编译包更省事但如果下游是 Qt MinGW 构建、或者混用了 GCC 工具链的 CMake 工程MSVC 编译的 GDAL 导入库.lib和运行库.dll在 ABI 层面就对不上。这就是很多人第一次翻车的地方——明明拿到了 GDAL 的 Windows 版链接时却一堆 unresolved external symbol。Cygwin 方案可以排除掉它编译出来的可执行文件依赖 Cygwin1.dll 那一套 POSIX 模拟层部署到没有装 Cygwin 的机器上就是一堆 DLL not found。MinGW-w64 是纯 Windows 原生工具链编译出的 GDAL 跑在 Windows 上不依赖额外运行时这才是老项目迁移时可接受的结果。具体选型上我用的是 MinGW-w64 的 GCC 8.x 系列。GDAL 1.11.5 的代码比较老太新的 GCC比如 13.x会暴露更多隐式声明的严格检查错误编译时污染会变多GCC 8 时代对 C89/C99 的老代码容忍度好很多。架构上先确认你下游工程是 32 位还是 64 位GDAL 两者的编译流程一致但路径完全不通选错了后面全部白搭。我一般先跑下面这条命令确认编译器位置gcc -v 21 | grep Target输出里会出现类似 x86_64-w64-mingw32 或 i686-w64-mingw32 的行。第一步就确认这个架构与你后续要链接的工程一致别信 PATH 里同时装了好几个 MinGW 的默认顺序——那是个经典的隐形坑。2.2 GDAL 1.11.5 的依赖链哪些必须编译哪些可以直接砍掉GDAL 1.11.5 的依赖数量和现代版本比不算多但每一个都涉及版本匹配。我最常踩的坑是把 proj 装成了新版本结果 GDAL configure 阶段虽然能过运行时一调用坐标转换函数就直接崩。按重要程度我把依赖分成三档依赖库建议版本是否必须作用proj4.8.0 ~ 4.9.3必须坐标参考系、投影转换核心GEOS3.4.x ~ 3.5.x强烈建议几何操作、空间关系判断libtiff4.0.x必须TIFF 驱动底层libpng / zlib老版本即可必须PNG 读写与压缩支撑libjpeg9.x可选JPEG 驱动SQLite3.x可选GPKG / VRT 等驱动依赖curl老版本即可可选WMS / TMS 等网络驱动xerces-c不装不建议复杂度高除非确定需要 XML 驱动关于 proj 版本这里有一条重要经验GDAL 1.11.5 的代码是按 proj 4 API 写的而 proj 5.0 开始把数据结构从 projPJ 改成了 PJ*坐标转换函数签名也变了。如果你系统里已经有新版 projGDAL 1.11.5 源码在编译期可能靠头文件兼容性蒙混过关但链接期或者运行期出问题的概率极高。我见过一个项目因此出现 getproj 返回空指针却没有报错的现象排查了一整天最后发现是动态链接时的 proj DLL 版本不对。所以依赖版本锁死这一步务必在 configure 之前完成不要图省事用系统里已有的新版本。2.3 工作目录与路径规划避免中文路径、空格和权限问题这一步看起来琐碎实际上决定了整个编译过程能不能顺完。很多人从网上下载源码包之后直接解压到了桌面的中文文件夹里或者解压到了带空格的 Program Files 下然后 configure 阶段报一些莫名其妙的路径错误。MinGW 工具链在旧版本时代对非 ASCII 路径的处理非常差GDAL 1.11.5 的构建脚本也继承了那个时代的脾气。我的做法是固定一个纯英文无空格的目录结构C:\gdal_build\ src\ # 所有源码包解压后的位置 deps\ # 依赖库的源码与编译产物 install\ # 最终安装根目录含 bin, lib, include我之间遇到过某开发者在 D:\工作资料\GIS项目\ 下面编译configure 能过但 make 到一半报找不到头文件最后把整个目录挪到 C:\gdal_build 就好了。这类问题浪费的时间完全可以通过开始之前就把路径定好来规避。另外一个建议把编译目录放在和 MinGW 工具链同一个盘符下避免跨盘操作带来的一些文件路径拼接问题。提示确认一下你的 MinGW-w64 安装目录里没有空格。默认装在 C:\mingw-w64 没问题但如果你装到了 C:\Program Files\mingw-w64后续 configure 时引号处理会很折磨。3. 依赖库先行走一遍proj 与 GEOS 的 configure 编译要点3.1 proj 4.9.3 的 configure 与 make锁定 API 版本先把 proj 编出来因为 GDAL 的 configure 脚本会去查找 proj 的头文件和库文件找不到就直接跳过 PROJ 支持而你只想用却不知道它被跳过了。我一般用 4.9.3 这个版本它是 proj 4 系列的最后一个稳定版对 GDAL 1.11.5 的兼容性最好。在 MSYS2 或 MinGW shell 里执行cd /c/gdal_build/deps/proj-4.9.3 ./configure --prefix/c/gdal_build/install \ --disable-shared \ --enable-static make -j4 make install这里几个参数解释一下。--prefix指定安装位置GDAL 后续 configure 会顺着这个路径去找 proj--disable-shared --enable-static是我个人推荐——静态链接 proj 可以避免运行时出现 proj.dll 找不到或者 DLL 版本冲突的问题代价是编译后的 GDAL 文件体积大一些但对老项目部署来说省心很多。如果不想用静态链接取消这两行参数即可。但要注意动态链接的话后续 GDAL 编译完一定要把 proj.dll 复制到 GDAL 的 bin 目录或者系统 PATH 里。这个问题后面避坑章节还会展开讲。make -j4 之后要确认安装产物ls /c/gdal_build/install/include/proj_api.h ls /c/gdal_build/install/lib/libproj.a如果 libproj.a 存在说明静态库编译成功。如果这两个文件缺失不要进入下一步回头去看 configure 输出里的错误。常见原因是 shell 环境里没有启用必要的工具比如 make 或 libtool。3.2 GEOS 的静态库编译与 C 运行时一致性问题GEOS 是 GDAL 几何功能的基础很多人在 CMake 工程里开着它结果编译完发现 GDAL 没有 GEOS 支持原本能跑的空间相交分析全挂了。GEOS 3.5.x 是 GDAL 1.11.5 时代比较匹配的版本3.6 以上在 Windows 上的构建脚本有点变化没必要冒险。cd /c/gdal_build/deps/geos-3.5.2 ./configure --prefix/c/gdal_build/install \ --disable-shared \ --enable-static make -j4 make installGEOS 是 C 写的这里要特别注意一个约束用它静态链接出来的 GDAL 以及后续你自己的 C 工程编译器必须保持同一个来源。如果 GDAL 用 MinGW GCC 8 编你自己的工程却用 MinGW GCC 13 或 MSVC链接时会有非常多 C 标准库符号冲突。这不是 GDAL 的问题是 C ABI 的问题。我之前在某跨平台系统项目里就因为这个查了很久最后发现是工程 A 用了 GCC 11 编的 GEOS 静态库工程 B 用 GCC 8 链接表现是各种内存崩溃。所以编译顺序上我强烈建议先确认整套工具链统一再开始编依赖。有一个简单确认命令gcc --version g --version make --version把这三个输出确认完之后再去编依赖。不要相信 PATH 里前面的编译器要对一下版本字符串是否一致。3.3 确认依赖库被 GDAL configure 正确识别这一步是很多人跳过的环节。GDAL 的 configure 如果在探测 proj 或 GEOS 时失败不会直接报错中止而是静默地把相关驱动标记为不可用。等你编译完用 gdalinfo --formats 一看少了 PROJ 或 GEOS 相关的能力才意识到之前白干了。我建议在开始 GDAL configure 之前手动跑一下依赖库的探测命令# 检查 proj 头文件和库是否可被找到 echo #include proj_api.h | gcc -I/c/gdal_build/install/include -E - /dev/null echo proj header OK # 检查 GEOS 头文件和库 echo #include geos_c.h | gcc -I/c/gdal_build/install/include -E - /dev/null echo geos header OK这两条命令如果输出 OK说明头文件路径没问题。库文件能链接的事情GDAL 的 configure 脚本会在之后的编译期自行验证只要头文件能找到configure 的探测一般都能过。如果头文件就找不到回去检查上面安装步骤的 --prefix 是否生效。提示有些系统的 gcc 默认不搜索 /usr/local/include 以外的路径MinGW 更是只搜自己安装目录。用 -I 显式指定是标准做法别指望 configure 脚本自动能找到。4. GDAL 1.11.5 本体 configure 与 make关键参数与两轮编译策略4.1 configure 的关键参数不要贪多只开需要的驱动GDAL 的 configure 支持一大堆 --with-* 参数。第一次编译时我的建议是只打开你确定要用的功能无关驱动全部 --without 或 --disable减少编译期间翻车的概率。下面是经过验证的最小化配置cd /c/gdal_build/src/gdal-1.11.5 ./configure --prefix/c/gdal_build/install \ --with-proj/c/gdal_build/install \ --with-geos/c/gdal_build/install/bin/geos-config \ --with-libtiff/c/gdal_build/install \ --with-libpng/c/gdal_build/install \ --with-libz/c/gdal_build/install \ --without-pam \ --without-xml2 \ --without-curl \ --without-sqlite3 \ --without-expat \ --without-xerces \ --without-openjpeg \ --without-python参数含义逐个说--with-proj后面跟的是 proj 安装前缀--with-geos指向 geos-config 脚本的路径GDAL 靠它来获取 GEOS 的编译参数这一步经常有人只写--with-geosyes结果 configure 找不到 geos-config 就悄悄跳过--with-libtiff、--with-libpng、--with-libz分别指到刚才安装依赖的前缀目录。--without-pam关闭了 GDAL 的持久化辅助数据管理功能这个是老版本在 Windows 上容易出问题的地方--without-python先关掉 Python 绑定把 C 核心编出来再说。剩下的逐个 disable 是为了缩短编译时间和减少翻车点。如果后面确实需要 SQLite 或者网络驱动再回头单独打开重编也不迟GDAL 增量编译的效率还可以。4.2 make -j4 的并行度选择与老代码的隐式声明问题configure 通过之后进入编译阶段。这里有一条我个人总结的经验第一遍编译不要用 -j4 以上的并行度。make -j4 -k 21 | tee build.log-k参数让 make 在遇到单个文件编译错误时尽量继续编译其他文件这样可以一次性收集全部错误。之后统一查看 build.logtee 命令同时把输出写到文件和屏幕。GDAL 1.11.5 在较新的 GCC 下最容易报的一类错误是implicit declaration of function。比如某些源文件用到strcasecmp但没包含对应的头文件老 GCC 只给 warning新 GCC 直接给 error。如果遇到这类错误常见的改动是在报错文件里手动加一行#include strings.h或者把 Makefile 里的 CFLAGS 加上-D_CRT_SECURE_NO_WARNINGS和-Wno-implicit-function-declaration。后者更省事因为老 GDAL 源码里这类问题不止一处一个个手动加太累。make CFLAGS-O2 -Wno-implicit-function-declaration -D_CRT_SECURE_NO_WARNINGS -j4 -k 21 | tee build2.log注意这里要重新跑 configure 才会把 CFLAGS 固化进 Makefile如果直接在 make 命令行覆盖有些子目录的编译规则会不认。我对这个问题的处理办法是改 configure 生成后的 GDALmake.opt 文件把 CFLAGS 那一行替换成带警告豁免的版本。具体路径是根目录下生成的 GDALmake.opt打开找到 CFLAGS 行直接改。4.3 make install 安装与输出目录整理编译通过后安装过程本身的坑不多但有一个细节要注意make install 默认把所有东西散落安装到 --prefix 下的 include、lib、bin 三个目录而 GDAL 1.11.5 的安装逻辑会把 20 多个 DLL 全部扔进 bin 里并不为每个驱动建子目录。这意味着部署时要么把 bin 整个加入 PATH要么直接把需要的 DLL 复制到应用目录。make install # 安装后确认目录结构 ls /c/gdal_build/install/bin ls /c/gdal_build/install/lib ls /c/gdal_build/install/include安装完成后bin 目录下应该能看到 gdalinfo.exe、gdal_translate.exe 这些工具lib 目录下应该有 libgdal.a如果你按上面的 configure 走的是静态库或 gdal.dll 的导入库。include 目录下是 gdal_priv.h、gdal.h 这些头文件。此时验证一下命令行工具能否运行/c/gdal_build/install/bin/gdalinfo.exe --version如果报缺 DLL别急下一章专门排查这类问题。5. 避坑与排查从 DLL 找不到到 ABI 混用五条实战经验5.1 运行时报“找不到 libproj.dll”或“找不到 libgdal-1.dll”现象gdalinfo.exe 能编译出来但一执行就弹窗或者命令行报 error while loading shared libraries。原因MinGW 编译的动态库在运行时按以下顺序找依赖 DLL应用程序所在目录、当前工作目录、系统 PATH。GDAL 的 DLL 和 proj 的 DLL 虽然都在 /c/gdal_build/install/bin 下但 gdalinfo.exe 所在的目录可能没被加入 PATH。解决把 install/bin 手动加入系统 PATH或者把需要的 DLL 全部复制到 gdalinfo.exe 所在目录。我一般用后者因为部署到客户机器时不应该依赖修改系统环境变量。复制清单包括 gdal 主 DLL、proj DLL如果你没静态编译 proj、GEOS DLL、libtiff DLL、libpng DLL。如果你按前文推荐的静态编译了 proj 和 GEOS这里只需要 gdal 主 DLL 和 zlib、libpng、libtiff 这几个少很多麻烦。5.2 坐标转换结果全错proj 版本被新库劫持现象程序能跑但用 GDAL 做投影转换输出的坐标明显不对甚至出现极点坐标或者接近零的值但没有任何崩溃和报错。原因机器上安装了新版 proj比如 proj 6/7它在 PATH 里的优先级比 GDAL 安装目录更高。GDAL 1.11.5 运行时按 DLL 搜索顺序找到了新版 proj.dll而新版 proj API 的数据结构变了GDAL 老代码按老 API 传参结果就是解析错误。解决两种方案任选。一是把 GDAL 安装目录的 bin 放到 PATH 最前面确保老版 proj DLL 先被加载二是用 Process Explorer 或 Dependencies 工具查一下 gdalinfo.exe 实际加载的 proj DLL 路径确认版本。方案二更稳妥因为 PATH 顺序问题在复杂环境里很容易反复。我现在每换一次环境都会先跑一遍 gdaltransform 做一个已知坐标点的转换验证省得后面排错排半天。5.3 GEOS 静态库混用 Different 编译器导致崩溃现象程序运行时调用 GEOS 的空间关系函数时而正常时而崩溃而且崩溃点会飘不是固定的栈。原因GEOS 是按 C 编译的它的静态库包含 C 标准库符号。如果你的工程用 MSVC 或另一个 GCC 版本链接这个库两个编译器的 std::string 内部布局不一致函数调用时栈破坏就会出现这种间歇性崩溃。解决从源头避免——GEOS、GDAL、你的工程三者必须用同一个 MinGW-w64 编译器编译。如果工程里历史遗留了 MSVC 编译的库要么把它换成 MinGW 版本要么让 GDAL 不启用 GEOS 支持。二选一没有第三种方案。我见过有人在两者之间反复调内存对齐参数把时间浪费在玄学上。5.4 configure 静默跳过 GEOS / proj 支持现象编译全程无错误但 gdalinfo --formats 列出格式时某些需要 GEOS 或 proj 的驱动不见了。原因GDAL 的 configure 脚本对可选依赖的处理策略是找不到就跳过不警告也不报错。常见的触发点是 geos-config 脚本路径没写对或者 proj 的头文件版本和库版本不一致。解决configure 之后立即检查生成的 GDALmake.opt 文件搜索 GEOS 和 PROJ 相关行。确认PROJ_FLAGS -DHAVE_PROJ GEOS_CONFIG /c/gdal_build/install/bin/geos-config如果这两行不是期望值说明探测失败了。回到依赖库安装步骤检查头文件路径然后再重新 configure。这时候别急着 make把 configure 输出从头到尾读一遍看有没有 misleading 的警告。5.5 链接时报大量未定义引用库的链接顺序现象自己的 C 工程链接 GDAL 静态库时报一堆未定义的符号比如 GDALAllRegister 或 OGRRegisterAll 找不到。原因MinGW 的链接器对静态库的扫描顺序是线性的而 GDAL 内部各模块之间有循环依赖。如果你在 g 命令行或 Makefile 里把 -lgdal 放在别的库之前链接器扫描到 GDAL 还没解析完等扫到后面的库时就无法回头找 GDAL 里的符号了。解决把 -lgdal 放在所有依赖库之后同时补上它的完整依赖链g main.cpp -o app.exe \ -L/c/gdal_build/install/lib \ -lgdal \ -lproj -lgeos -ltiff -lpng -lz如果还缺符号再从 GDAL 编译日志里找它实际链接了哪些库逐个补上。这是我在某图像处理 Demo 里踩过的坑当时把库写成-lproj -lgeos -lgdal链接器一直报错反过来之后就好了。6. 验证与后续维护从最小测试到版本锁定的习惯6.1 用 gdalinfo 和一张小影像做最小验证编译完不是终点先跑一个跨格式转换的测试验证 proj 和 GEOS 真的生效了。准备一张任意 TIFF 影像运行gdalinfo.exe test.tif gdalinfo.exe --formats | grep -i GTiff看到 GTiff 驱动在列表里说明 libtiff 工作正常。接着用一个带投影的影像测试坐标转换gdalwarp.exe test.tif test_4326.tif -t_srs EPSG:4326如果这条命令能成功输出说明 proj 的坐标转换链路完整可用。这是我最常用的一组最小验证五个命令以内确认整套编译没有白干。6.2 Qt / C 工程链接 MinGW 版 GDAL 的最小配置老项目用 Qt 的 MinGW 构建链很常见我的 .pro 文件里是这么写的INCLUDEPATH C:/gdal_build/install/include LIBS -LC:/gdal_build/install/lib -lgdal关键在于 LIBS 的顺序把 -lgdal 放最后面可以减少未定义引用的问题。同时确认 Qt 的编译器 kit 和编 GDAL 用的 GCC 版本一致这一点前面已强调不再重复。6.3 记录 configure 参数与依赖版本避免重蹈覆辙最后提一个我自己的习惯每次编译完我会把用到的 configure 命令、依赖库版本、编译器版本、修改过的 GDALmake.opt 内容保存成一个 rebuild_notes.txt 放在源码目录旁边。这个东西平时没什么用但半年后重新构建或者换机器时能省掉半天摸索时间。GDAL 1.11.5 这套东西重新编译的成本不低依赖链上的版本锁定一旦没记录下次就可能因为 proj 版本漂移而翻车。我的教训是某次换电脑重建环境仗着记忆重新编依赖结果 proj 装成了 5.xGDAL 编译时没问题运行测试时才发现坐标转换全错排查了几乎一整天。从那以后所有老版本 GDAL 的编译环境我都强制要求记录版本和 configure 参数。希望这些小习惯能帮到你让你在这条路上少走几步弯路。本文还有配套的精品资源点击获取
