简介基于msys2与mingw64工具链预编译的GDAL 1.11.5库专为Windows下的QtMinGW版C开发者准备帮助省去自行编译与依赖配置的麻烦。库包涵盖核心动态库、静态库与头文件适合需要快速集成GDAL进行栅格/矢量读写、投影转换等GIS开发场景。压缩包共149个文件包括63个h头文件、28个csv坐标与投影参数文件、22个exe命令行工具以及dll/a库文件、wkt/dxf样例数据等包体约70.71MB目录结构清晰便于直接引用。目前已有1514人学习下载实用价值经受了验证。包内附有gdal-config配置脚本与常用数据驱动支持文件并针对Qt环境下程序异常结束的问题提供了排查参考链接可帮助开发者在实际项目中少走弯路、快速调通编译与运行环境。 打开一个老GIS项目时如果发现它背后依赖的是mingw64编译的GDAL 1.11.5你多半已经踩到了Windows环境下最让人头疼的几个坑老版本没有官方构建包、MSVC编译总差那么几个依赖、换新版本又怕行为不一致。这篇文章就讲我怎么把这条路走通的。GDAL是地理空间数据领域绕不开的底层库负责把几十种栅格格式和几十种矢量格式的读写、投影转换、几何运算统一成一套API。1.11.5这个版本虽然老在一些生产系统、业务插件、算法封装里仍然被死死锁定不能随便升。而mingw64这套开源编译链正好是Windows上能不能顺利编出它的分水岭。内容会从方案选型、环境准备、完整编译命令一路讲到运行时排错和Python绑定的取舍想复现的人可以直接照着抄只想了解原理的人也能看明白每一步为什么这么做。1. 为什么要在mingw64下折腾GDAL 1.11.51.1 老版本GDAL的生命力在哪里很多人不理解GDAL都出到3.x了连新版本都有现成wheel包可以pip安装为什么还要回头折腾1.11.5。我在实际项目里遇到的情况是这样客户那边有一套封闭的算法模块SDK明确要求链接GDAL 1.x的C接口或者老的业务数据流里用了某些早期驱动新版本改动了默认行为和错误返回码上线前根本不敢换。另一个常见场景是嵌入式或工控机环境。这些设备操作系统老旧、权限受限既没有conda也没有完整MSVC运行时必须把GDAL静态或半静态地编进主程序里。这时候老版本反而成了“稳定”的代名词因为它的依赖面窄、行为已经被无数项目验证过1.11.5又是1.11系列最后的补丁版本属于老项目里很常见的锁定目标。所以“mingw64编译的GDAL 1.11.5”这个需求不是考古而是真实的生产需求。它要解决的核心问题是在没有MSVC商业许可、不想装完整Visual Studio、又要能产出干净DLL的Windows环境下如何获得一个可控、可复现、可调试的GDAL库。1.2 MinGW-w64与MSVC方案怎么选我最早也试过用MSVC去编GDAL 1.11.5。结论是能编但非常痛苦。GDAL 1.x时代的部分C写法在新版MSVC下会触发各种兼容性报错你得手动改源码更麻烦的是依赖库libtiff、geotiff、proj、curl这些第三方库在Windows下用MSVC编每一条都要单独配置版本还得彼此匹配稍有不慎就在链接阶段崩掉。MinGW-w64方案的优势第一是开源工具链没有许可问题第二是它和Linux下的GCC行为很接近GDAL 1.x的configure脚本几乎不用改就能直接跑第三是MSYS2环境提供了pacman包管理器很多依赖库可以直接装预编译版本省掉自己编依赖的大半时间。从部署角度看MinGW-w64编出的DLL对运行时环境的依赖也更简单。它不要求目标机器装VC Redistributable很多时候只需要把GDAL的DLL和几个MinGW运行库一起拷过去就能跑。这一点在老服务器、工控机上非常加分。1.3 1.11.5这个版本号值得注意的地方具体到1.11.5这个版本号有几个技术细节会影响你后面的编译参数。首先是它默认不开启C11源码大量使用老式指针和C风格接口编译器的差异主要体现在模板和命名空间处理上GCC系的MinGW-w64反而比MSVC更贴近它当年开发时的环境。其次是它依赖的PROJ库版本是4.x系列不是现在主流的PROJ 6/7/8。PROJ 4里的头文件叫proj_api.h新版PROJ早就移除了这个头文件。如果你直接用MSYS2里默认的PROJ版本去编GDAL 1.11.5configure阶段就可能报找不到proj_api.h。这一点后面会详细讲它是我见过最常见的老GDAL编译失败原因。还有一点是它的Python绑定默认适配Python 2.7或早期Python 3.x。到了今天如果你想把这个老版本绑到Python 3.10上基本等于自己给自己挖坑。我的建议是明确边界编译目标到底是C库本身还是连Python绑定一起要。这两个需求的技术路线完全不同。2. 编译前准备工具链、依赖库与环境规划2.1 工具链和第三方库清单我用的基础环境是MSYS2 MinGW-w64。MSYS2的安装很简单官网下载安装包装完以后你会得到MSYS2 Shell和MinGW-w64 Shell两个入口。注意编译GDAL一定要从“MinGW-w64 64-bit”那个入口进不要从普通的MSYS2 Shell进否则默认用的不是x86_64的GCC。进入后先更新核心工具链pacman -Syu更新完可能需要重启终端。接着安装编译GDAL 1.11.5需要的依赖pacman -S mingw-w64-x86_64-gcc mingw-w64-x86_64-make \ mingw-w64-x86_64-pkgconf 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-geotiff \ mingw-w64-x86_64-sqlite3 mingw-w64-x86_64-expat \ mingw-w64-x86_64-curl mingw-w64-x86_64-proj这里要说一个容易犯的错很多教程会让你装不带mingw-w64-x86_64前缀的包比如直接装proj这会把依赖装进MSYS2自身环境而不是MinGW-w64环境编译时GCC根本找不到头文件。认准mingw-w64-x86_64-前缀装进去的东西才在你的编译器搜索路径里。2.2 环境变量和目录结构的坑位预排目录规划上我建议把源码和安装目录分开并且路径不要有空格。GDAL的configure脚本对路径里有空格这件事处理得很粗糙Windows用户名如果叫“Zhang San”编译时各种绝对路径拼接就会出问题。我的习惯是这样源码目录/c/gdal-1.11.5-source 安装目录/c/gdal-1.11.5-install在MSYS2的MinGW-w64 Shell里Windows的C盘显示为/c/D盘是/d/。configure脚本里传路径时可以用--prefix/c/gdal-1.11.5-install也可以写Windows风格路径。但更稳妥的是用MSYS风格少一层转换就少一类坑。另外如果你的系统里装了Anaconda或者其他Python发行版我强烈建议临时把它们的bin目录从PATH里摘出去。Anaconda会带一份自己的libstdc、libgcc还有可能拦截make、pkg-config各种莫名其妙的头文件冲突基本都是这么来的。临时用export PATH/mingw64/bin:/usr/bin:/bin把PATH收干净能省掉无数排查时间。2.3 提前说清楚配置失败的两种典型原因结合我踩坑的经验GDAL 1.11.5的configure失败90%是两类原因。第一类是PROJ相关的问题。configure脚本会找proj_api.h和libproj而新版PROJ 6已经完全移除了proj_api.hGDAL 1.11.5根本认不出来。解决方案是装一个PROJ 4.x或者4.9.x系列的版本。MSYS2的仓库版本可能比较新如果遇到这个问题可能需要手动下载老版PROJ源码编一遍或者从其他渠道获取老版二进制。这个判断标准很简单configure日志里看到“checking for proj_api.h... no”基本就可以确定是PROJ版本太新了。第二类是pkg-config路径没配对。GDAL的configure会调用pkg-config去探测libcurl、libtiff等依赖如果这些库装在了一个pkg-config搜索不到的位置它就会静默跳过对应驱动最后编出来的GDAL功能缺一截。可以通过PKG_CONFIG_PATH/mingw64/lib/pkgconfig手动指定然后再跑configure这样依赖命中率会高很多。3. configure/make/install核心编译流程实录3.1 configure参数怎么给最稳进入源码目录后我用的configure命令大概是这个样子的cd /c/gdal-1.11.5-source ./configure \ --prefix/c/gdal-1.11.5-install \ --with-ogr \ --without-libtool \ --with-png/mingw64 \ --with-libtiff/mingw64 \ --with-geotiff/mingw64 \ --with-jpeg/mingw64 \ --with-sqlite3/mingw64 \ --with-proj/mingw64 \ --with-curl/mingw64简单解释每个参数的作用。--prefix指定安装路径后面make install会把头文件和库文件放到这里。--with-ogr开启矢量驱动框架这是必须的否则连Shapefile都读不了。--without-libtool去掉libtool的包装MinGW下直接用GCC的链接流程更不容易出幺蛾子。后面的--with-*参数指定关键第三方库的安装位置/mingw64是MSYS2里MinGW-w64包的默认安装根目录。configure跑完后重点看两处一是结尾的汇总信息里面列出了将要编译的驱动列表二是日志里有没有出现WARNING或者not found的字样。如果某个驱动不想要可以直接不写对应的--with-*参数特别是那些牵扯到复杂依赖的驱动宁可少开几个也别让整个编译卡住。3.2 并行make的使用与检查configure成功后就是编译make -j4-j4表示同时用4个线程编译实际数字根据CPU核心数和内存大小调整。我建议先别直接把-j拉满因为GDAL源码编译时会临时生成大量C中间文件内存不够时会触发OOM进程被杀死后你还得重新从头编译反倒更慢。我自己在8核16G内存的机器上用-j6比较舒服如果是4G内存的老机器-j2更稳。编译过程中的日志很长不用一直盯着。重点看收尾阶段有没有出现类似Linking CXX shared library libgdal-1.dll的信息这说明核心库正在链接到了这一步基本就稳了。如果中途失败不要急着重新跑make先去找最后几行错误信息。MinGW下最常见的编译失败原因其实是头文件路径冲突比如它在系统头文件里找到了一个错误版本的cpl_config.h。3.3 install后的库文件落位编译完成后执行make install安装完成后/c/gdal-1.11.5-install下会多出来三个主要目录bin/ # libgdal-1.dll、gdalinfo.exe、ogrinfo.exe等 include/ # gdal.h、gdal_priv.h、cpl_*.h等头文件 lib/ # libgdal.dll.a、libgdal.a等静态链接库文件这里有个容易混淆的地方MinGW-w64生成的导入库后缀是.dll.a不是MSVC的.lib。如果你后续要在别的C项目里链接这个GDAL链接的是libgdal.dll.a这属于MinGW体系的标准产物。如果你用的还是MSVC的项目那就去用MSVC的.lib两边不要混着链。验证安装版本/c/gdal-1.11.5-install/bin/gdalinfo.exe --version正常输出会显示GDAL 1.11.5的版本字符串以及编译时的一些配置信息。看到这个核心库就算真正落地了。4. 功能验证与问题排查实录4.1 用gdalinfo和ogrinfo验证编译结果编译安装完成后的第一件事不是急着接到业务代码里而是先验证功能完整性。我一般用三个命令gdalinfo --version gdalinfo --formats | less ogrinfo --formats | lessgdalinfo --formats会列出当前GDAL支持的所有栅格格式ogrinfo --formats列出矢量格式。重点检查几个常用驱动GTiff、ESRI Shapefile、PNG、JPEG、GeoJSON、SQLite。如果这些都在核心功能基本没问题。我遇到过一种情况编译时没有指定--with-png和--with-jpeg结果GDAL自己编进去了一个内置的旧版本实现也能读出PNG/JPEG但后续和外部图像库对接时接口行为不一致。所以make install之后检查格式列表时要顺手确认它到底用的是内置驱动还是外部库驱动configure日志里都会有记录。4.2 运行时缺DLL的定位与解决把编译出来的gdalinfo.exe拷到一台没有MSYS2的机器上运行最常见的错误是这个error while loading shared libraries: libgdal-1.dll: cannot open shared object file遇到这个问题先别慌这不是GDAL本身编坏了而是运行时动态链接器找不到DLL。老版本GDAL在Windows下编出来默认是个动态库libgdal-1.dll它自身还会依赖libgcc_s_seh-1.dll、libstdc-6.dll、libwinpthread-1.dll这些MinGW运行库以及libpng、libjpeg等第三方DLL。排查依赖最顺手的工具是ntlddpacman -S mingw-w64-x86_64-ntldd ntldd -R /c/gdal-1.11.5-install/bin/gdalinfo.exe它会列出gdalinfo.exe依赖的所有DLL从中就能看到哪些来自/mingw64/bin、哪些来自GDAL自己的安装目录。把这些缺失的DLL拷到exe同目录或者干脆把/mingw64/bin加进系统PATH程序就能跑起来。在自己开发机上也常遇到这个问题原因是MSYS2 Shell里PATH包含了/mingw64/bin所以一切正常但你在VS Code或者系统CMD里运行时PATH里没有这个目录。这时候优先推荐加系统PATH而不是往每个项目里拷DLL一是省空间二是后续升级依赖不用重新拷一遍。4.3 一批容易踩的编译期报错速查报错信息原因解决办法checking for proj_api.h... noPROJ版本太新缺少老接口换用PROJ 4.x系或手动指定老版头文件路径jpeglib.h / png.h not found第三方库路径未指定显式加--with-jpeg/mingw64、--with-png/mingw64gdal-config not found依赖的GDAL开发包缺失先完整编译并make install再让依赖方用安装目录里的gdal-configundefined reference to__imp_...链接时导入了MSVC的lib确认项目里用的是MinGW的libgdal.dll.a不是MSVC的.libcannot find -lprojProj库名不匹配确认libproj.dll.a存在于lib目录并正确传入--with-proj一个通用排错思路configure和make的日志不要滚动完就扔先搜error、warning、No such file这几类关键词能省很多时间。我在给客户排障时经常第一句就问“configure日志里的最后三行是什么”90%的问题当场就能定位。5. Python绑定与后续使用建议5.1 老版本Python绑定为什么值得自己编如果项目不只是C要用还想着在Python里调GDAL 1.11.5那就得额外说清楚。新版GDAL直接pip install gdal就能拿到对应cp版本的whl比如现在常见的gdal 3.10.1 cp313 cp313 win_amd64.whl装完就能用。但GDAL 1.11.5这个年代的Python绑定官方渠道早就没有预编译wheel了conda-forge上也没有老版本维护。你要么从老乡的网盘里找当年留下的轮子要么自己编。自己编的路子是GDAL源码里自带swig/python目录里面有setup.py在configure完成、核心库编译成功后进到这个目录去编Python绑定。cd /c/gdal-1.11.5-source/swig/python python setup.py build这个流程在Python 2.7时代是很顺畅的。如果你面对的Python版本是3.8甚至更高我劝你慎重老版本绑定的代码里大量使用Python 2时代的API虽然多数能被2to3工具转换但转换后还会有一堆C扩展层的坑调起来比重新编译GDAL还耗时。我的个人建议需要Python GDAL功能就用新版需要GDAL 1.11.5就用C接口两边各管一摊别强行混在一起。如果确实必须在现代Python环境里用老版本GDAL优先去翻一翻有没有第三方做过的老版本轮子其次再考虑自己折腾绑定源码时间成本差一个量级。5.2 我踩过的一些“隐藏坑”最后分享两个容易被忽视的经验。第一configure参数一定要留档。GDAL的configure参数在编译完成后找不回来下次重新编译就只能凭记忆。我后来习惯把configure命令原样写在一个build.sh里放在源码目录同级这样不管是自己隔了半年再重新编还是同事接手一条命令回放环境一摸一样不用再靠大脑回忆参数。第二别一开始就贪多。第一次在mingw64下编GDAL 1.11.5先用最小配置把基础库编出来确认工具链和依赖路径都没问题再去加--with-curl、--with-expat这些复杂驱动。一次加一个依赖能精准定位到是哪个库引起的configure失败而不是几十个报错叠在一起无从下手。这个思路适用于几乎所有开源库的Windows编译不单单是GDAL。从实际项目角度看mingw64编译的GDAL 1.11.5解决的是“老版本在新环境下的可复现构建”问题。工具链选对了依赖版本控住了编译过程其实可以像Linux下一样顺畅。希望这篇踩坑记录能让你少走一段弯路。本文还有配套的精品资源点击获取
MinGW-w64编译GDAL 1.11.5：Windows老版本构建实战指南
简介基于msys2与mingw64工具链预编译的GDAL 1.11.5库专为Windows下的QtMinGW版C开发者准备帮助省去自行编译与依赖配置的麻烦。库包涵盖核心动态库、静态库与头文件适合需要快速集成GDAL进行栅格/矢量读写、投影转换等GIS开发场景。压缩包共149个文件包括63个h头文件、28个csv坐标与投影参数文件、22个exe命令行工具以及dll/a库文件、wkt/dxf样例数据等包体约70.71MB目录结构清晰便于直接引用。目前已有1514人学习下载实用价值经受了验证。包内附有gdal-config配置脚本与常用数据驱动支持文件并针对Qt环境下程序异常结束的问题提供了排查参考链接可帮助开发者在实际项目中少走弯路、快速调通编译与运行环境。 打开一个老GIS项目时如果发现它背后依赖的是mingw64编译的GDAL 1.11.5你多半已经踩到了Windows环境下最让人头疼的几个坑老版本没有官方构建包、MSVC编译总差那么几个依赖、换新版本又怕行为不一致。这篇文章就讲我怎么把这条路走通的。GDAL是地理空间数据领域绕不开的底层库负责把几十种栅格格式和几十种矢量格式的读写、投影转换、几何运算统一成一套API。1.11.5这个版本虽然老在一些生产系统、业务插件、算法封装里仍然被死死锁定不能随便升。而mingw64这套开源编译链正好是Windows上能不能顺利编出它的分水岭。内容会从方案选型、环境准备、完整编译命令一路讲到运行时排错和Python绑定的取舍想复现的人可以直接照着抄只想了解原理的人也能看明白每一步为什么这么做。1. 为什么要在mingw64下折腾GDAL 1.11.51.1 老版本GDAL的生命力在哪里很多人不理解GDAL都出到3.x了连新版本都有现成wheel包可以pip安装为什么还要回头折腾1.11.5。我在实际项目里遇到的情况是这样客户那边有一套封闭的算法模块SDK明确要求链接GDAL 1.x的C接口或者老的业务数据流里用了某些早期驱动新版本改动了默认行为和错误返回码上线前根本不敢换。另一个常见场景是嵌入式或工控机环境。这些设备操作系统老旧、权限受限既没有conda也没有完整MSVC运行时必须把GDAL静态或半静态地编进主程序里。这时候老版本反而成了“稳定”的代名词因为它的依赖面窄、行为已经被无数项目验证过1.11.5又是1.11系列最后的补丁版本属于老项目里很常见的锁定目标。所以“mingw64编译的GDAL 1.11.5”这个需求不是考古而是真实的生产需求。它要解决的核心问题是在没有MSVC商业许可、不想装完整Visual Studio、又要能产出干净DLL的Windows环境下如何获得一个可控、可复现、可调试的GDAL库。1.2 MinGW-w64与MSVC方案怎么选我最早也试过用MSVC去编GDAL 1.11.5。结论是能编但非常痛苦。GDAL 1.x时代的部分C写法在新版MSVC下会触发各种兼容性报错你得手动改源码更麻烦的是依赖库libtiff、geotiff、proj、curl这些第三方库在Windows下用MSVC编每一条都要单独配置版本还得彼此匹配稍有不慎就在链接阶段崩掉。MinGW-w64方案的优势第一是开源工具链没有许可问题第二是它和Linux下的GCC行为很接近GDAL 1.x的configure脚本几乎不用改就能直接跑第三是MSYS2环境提供了pacman包管理器很多依赖库可以直接装预编译版本省掉自己编依赖的大半时间。从部署角度看MinGW-w64编出的DLL对运行时环境的依赖也更简单。它不要求目标机器装VC Redistributable很多时候只需要把GDAL的DLL和几个MinGW运行库一起拷过去就能跑。这一点在老服务器、工控机上非常加分。1.3 1.11.5这个版本号值得注意的地方具体到1.11.5这个版本号有几个技术细节会影响你后面的编译参数。首先是它默认不开启C11源码大量使用老式指针和C风格接口编译器的差异主要体现在模板和命名空间处理上GCC系的MinGW-w64反而比MSVC更贴近它当年开发时的环境。其次是它依赖的PROJ库版本是4.x系列不是现在主流的PROJ 6/7/8。PROJ 4里的头文件叫proj_api.h新版PROJ早就移除了这个头文件。如果你直接用MSYS2里默认的PROJ版本去编GDAL 1.11.5configure阶段就可能报找不到proj_api.h。这一点后面会详细讲它是我见过最常见的老GDAL编译失败原因。还有一点是它的Python绑定默认适配Python 2.7或早期Python 3.x。到了今天如果你想把这个老版本绑到Python 3.10上基本等于自己给自己挖坑。我的建议是明确边界编译目标到底是C库本身还是连Python绑定一起要。这两个需求的技术路线完全不同。2. 编译前准备工具链、依赖库与环境规划2.1 工具链和第三方库清单我用的基础环境是MSYS2 MinGW-w64。MSYS2的安装很简单官网下载安装包装完以后你会得到MSYS2 Shell和MinGW-w64 Shell两个入口。注意编译GDAL一定要从“MinGW-w64 64-bit”那个入口进不要从普通的MSYS2 Shell进否则默认用的不是x86_64的GCC。进入后先更新核心工具链pacman -Syu更新完可能需要重启终端。接着安装编译GDAL 1.11.5需要的依赖pacman -S mingw-w64-x86_64-gcc mingw-w64-x86_64-make \ mingw-w64-x86_64-pkgconf 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-geotiff \ mingw-w64-x86_64-sqlite3 mingw-w64-x86_64-expat \ mingw-w64-x86_64-curl mingw-w64-x86_64-proj这里要说一个容易犯的错很多教程会让你装不带mingw-w64-x86_64前缀的包比如直接装proj这会把依赖装进MSYS2自身环境而不是MinGW-w64环境编译时GCC根本找不到头文件。认准mingw-w64-x86_64-前缀装进去的东西才在你的编译器搜索路径里。2.2 环境变量和目录结构的坑位预排目录规划上我建议把源码和安装目录分开并且路径不要有空格。GDAL的configure脚本对路径里有空格这件事处理得很粗糙Windows用户名如果叫“Zhang San”编译时各种绝对路径拼接就会出问题。我的习惯是这样源码目录/c/gdal-1.11.5-source 安装目录/c/gdal-1.11.5-install在MSYS2的MinGW-w64 Shell里Windows的C盘显示为/c/D盘是/d/。configure脚本里传路径时可以用--prefix/c/gdal-1.11.5-install也可以写Windows风格路径。但更稳妥的是用MSYS风格少一层转换就少一类坑。另外如果你的系统里装了Anaconda或者其他Python发行版我强烈建议临时把它们的bin目录从PATH里摘出去。Anaconda会带一份自己的libstdc、libgcc还有可能拦截make、pkg-config各种莫名其妙的头文件冲突基本都是这么来的。临时用export PATH/mingw64/bin:/usr/bin:/bin把PATH收干净能省掉无数排查时间。2.3 提前说清楚配置失败的两种典型原因结合我踩坑的经验GDAL 1.11.5的configure失败90%是两类原因。第一类是PROJ相关的问题。configure脚本会找proj_api.h和libproj而新版PROJ 6已经完全移除了proj_api.hGDAL 1.11.5根本认不出来。解决方案是装一个PROJ 4.x或者4.9.x系列的版本。MSYS2的仓库版本可能比较新如果遇到这个问题可能需要手动下载老版PROJ源码编一遍或者从其他渠道获取老版二进制。这个判断标准很简单configure日志里看到“checking for proj_api.h... no”基本就可以确定是PROJ版本太新了。第二类是pkg-config路径没配对。GDAL的configure会调用pkg-config去探测libcurl、libtiff等依赖如果这些库装在了一个pkg-config搜索不到的位置它就会静默跳过对应驱动最后编出来的GDAL功能缺一截。可以通过PKG_CONFIG_PATH/mingw64/lib/pkgconfig手动指定然后再跑configure这样依赖命中率会高很多。3. configure/make/install核心编译流程实录3.1 configure参数怎么给最稳进入源码目录后我用的configure命令大概是这个样子的cd /c/gdal-1.11.5-source ./configure \ --prefix/c/gdal-1.11.5-install \ --with-ogr \ --without-libtool \ --with-png/mingw64 \ --with-libtiff/mingw64 \ --with-geotiff/mingw64 \ --with-jpeg/mingw64 \ --with-sqlite3/mingw64 \ --with-proj/mingw64 \ --with-curl/mingw64简单解释每个参数的作用。--prefix指定安装路径后面make install会把头文件和库文件放到这里。--with-ogr开启矢量驱动框架这是必须的否则连Shapefile都读不了。--without-libtool去掉libtool的包装MinGW下直接用GCC的链接流程更不容易出幺蛾子。后面的--with-*参数指定关键第三方库的安装位置/mingw64是MSYS2里MinGW-w64包的默认安装根目录。configure跑完后重点看两处一是结尾的汇总信息里面列出了将要编译的驱动列表二是日志里有没有出现WARNING或者not found的字样。如果某个驱动不想要可以直接不写对应的--with-*参数特别是那些牵扯到复杂依赖的驱动宁可少开几个也别让整个编译卡住。3.2 并行make的使用与检查configure成功后就是编译make -j4-j4表示同时用4个线程编译实际数字根据CPU核心数和内存大小调整。我建议先别直接把-j拉满因为GDAL源码编译时会临时生成大量C中间文件内存不够时会触发OOM进程被杀死后你还得重新从头编译反倒更慢。我自己在8核16G内存的机器上用-j6比较舒服如果是4G内存的老机器-j2更稳。编译过程中的日志很长不用一直盯着。重点看收尾阶段有没有出现类似Linking CXX shared library libgdal-1.dll的信息这说明核心库正在链接到了这一步基本就稳了。如果中途失败不要急着重新跑make先去找最后几行错误信息。MinGW下最常见的编译失败原因其实是头文件路径冲突比如它在系统头文件里找到了一个错误版本的cpl_config.h。3.3 install后的库文件落位编译完成后执行make install安装完成后/c/gdal-1.11.5-install下会多出来三个主要目录bin/ # libgdal-1.dll、gdalinfo.exe、ogrinfo.exe等 include/ # gdal.h、gdal_priv.h、cpl_*.h等头文件 lib/ # libgdal.dll.a、libgdal.a等静态链接库文件这里有个容易混淆的地方MinGW-w64生成的导入库后缀是.dll.a不是MSVC的.lib。如果你后续要在别的C项目里链接这个GDAL链接的是libgdal.dll.a这属于MinGW体系的标准产物。如果你用的还是MSVC的项目那就去用MSVC的.lib两边不要混着链。验证安装版本/c/gdal-1.11.5-install/bin/gdalinfo.exe --version正常输出会显示GDAL 1.11.5的版本字符串以及编译时的一些配置信息。看到这个核心库就算真正落地了。4. 功能验证与问题排查实录4.1 用gdalinfo和ogrinfo验证编译结果编译安装完成后的第一件事不是急着接到业务代码里而是先验证功能完整性。我一般用三个命令gdalinfo --version gdalinfo --formats | less ogrinfo --formats | lessgdalinfo --formats会列出当前GDAL支持的所有栅格格式ogrinfo --formats列出矢量格式。重点检查几个常用驱动GTiff、ESRI Shapefile、PNG、JPEG、GeoJSON、SQLite。如果这些都在核心功能基本没问题。我遇到过一种情况编译时没有指定--with-png和--with-jpeg结果GDAL自己编进去了一个内置的旧版本实现也能读出PNG/JPEG但后续和外部图像库对接时接口行为不一致。所以make install之后检查格式列表时要顺手确认它到底用的是内置驱动还是外部库驱动configure日志里都会有记录。4.2 运行时缺DLL的定位与解决把编译出来的gdalinfo.exe拷到一台没有MSYS2的机器上运行最常见的错误是这个error while loading shared libraries: libgdal-1.dll: cannot open shared object file遇到这个问题先别慌这不是GDAL本身编坏了而是运行时动态链接器找不到DLL。老版本GDAL在Windows下编出来默认是个动态库libgdal-1.dll它自身还会依赖libgcc_s_seh-1.dll、libstdc-6.dll、libwinpthread-1.dll这些MinGW运行库以及libpng、libjpeg等第三方DLL。排查依赖最顺手的工具是ntlddpacman -S mingw-w64-x86_64-ntldd ntldd -R /c/gdal-1.11.5-install/bin/gdalinfo.exe它会列出gdalinfo.exe依赖的所有DLL从中就能看到哪些来自/mingw64/bin、哪些来自GDAL自己的安装目录。把这些缺失的DLL拷到exe同目录或者干脆把/mingw64/bin加进系统PATH程序就能跑起来。在自己开发机上也常遇到这个问题原因是MSYS2 Shell里PATH包含了/mingw64/bin所以一切正常但你在VS Code或者系统CMD里运行时PATH里没有这个目录。这时候优先推荐加系统PATH而不是往每个项目里拷DLL一是省空间二是后续升级依赖不用重新拷一遍。4.3 一批容易踩的编译期报错速查报错信息原因解决办法checking for proj_api.h... noPROJ版本太新缺少老接口换用PROJ 4.x系或手动指定老版头文件路径jpeglib.h / png.h not found第三方库路径未指定显式加--with-jpeg/mingw64、--with-png/mingw64gdal-config not found依赖的GDAL开发包缺失先完整编译并make install再让依赖方用安装目录里的gdal-configundefined reference to__imp_...链接时导入了MSVC的lib确认项目里用的是MinGW的libgdal.dll.a不是MSVC的.libcannot find -lprojProj库名不匹配确认libproj.dll.a存在于lib目录并正确传入--with-proj一个通用排错思路configure和make的日志不要滚动完就扔先搜error、warning、No such file这几类关键词能省很多时间。我在给客户排障时经常第一句就问“configure日志里的最后三行是什么”90%的问题当场就能定位。5. Python绑定与后续使用建议5.1 老版本Python绑定为什么值得自己编如果项目不只是C要用还想着在Python里调GDAL 1.11.5那就得额外说清楚。新版GDAL直接pip install gdal就能拿到对应cp版本的whl比如现在常见的gdal 3.10.1 cp313 cp313 win_amd64.whl装完就能用。但GDAL 1.11.5这个年代的Python绑定官方渠道早就没有预编译wheel了conda-forge上也没有老版本维护。你要么从老乡的网盘里找当年留下的轮子要么自己编。自己编的路子是GDAL源码里自带swig/python目录里面有setup.py在configure完成、核心库编译成功后进到这个目录去编Python绑定。cd /c/gdal-1.11.5-source/swig/python python setup.py build这个流程在Python 2.7时代是很顺畅的。如果你面对的Python版本是3.8甚至更高我劝你慎重老版本绑定的代码里大量使用Python 2时代的API虽然多数能被2to3工具转换但转换后还会有一堆C扩展层的坑调起来比重新编译GDAL还耗时。我的个人建议需要Python GDAL功能就用新版需要GDAL 1.11.5就用C接口两边各管一摊别强行混在一起。如果确实必须在现代Python环境里用老版本GDAL优先去翻一翻有没有第三方做过的老版本轮子其次再考虑自己折腾绑定源码时间成本差一个量级。5.2 我踩过的一些“隐藏坑”最后分享两个容易被忽视的经验。第一configure参数一定要留档。GDAL的configure参数在编译完成后找不回来下次重新编译就只能凭记忆。我后来习惯把configure命令原样写在一个build.sh里放在源码目录同级这样不管是自己隔了半年再重新编还是同事接手一条命令回放环境一摸一样不用再靠大脑回忆参数。第二别一开始就贪多。第一次在mingw64下编GDAL 1.11.5先用最小配置把基础库编出来确认工具链和依赖路径都没问题再去加--with-curl、--with-expat这些复杂驱动。一次加一个依赖能精准定位到是哪个库引起的configure失败而不是几十个报错叠在一起无从下手。这个思路适用于几乎所有开源库的Windows编译不单单是GDAL。从实际项目角度看mingw64编译的GDAL 1.11.5解决的是“老版本在新环境下的可复现构建”问题。工具链选对了依赖版本控住了编译过程其实可以像Linux下一样顺畅。希望这篇踩坑记录能让你少走一段弯路。本文还有配套的精品资源点击获取
 函数简化 CSS Grid 轨道模板)
