简介基于MSYS2与MinGW64编译完成的GDAL 1.11.5开发包供QtMinGW版环境下的C开发者直接使用解决GIS工程中GDAL库编译繁琐的问题。压缩包共149个文件约70.71MB以头文件、静态链接库、可执行工具和坐标参数CSV为主头文件与静态库用于Qt项目链接调用CSV提供投影、基准面与椭球参数exe支持命令行格式转换。包内另有dll、ini等配套文件解压后将bin目录加入环境变量并在.pro中配置include和lib路径即可接入若程序异常退出可参考作者排错博文快速定位。目前已有1514人学习下载适合需要快速集成GDAL地理数据处理能力的MinGW64使用者。 说实话如果只是想在Windows上用GDAL处理数据我完全不建议去折腾编译——pip install gdal或者直接拉一个OSGeo4W安装包几分钟就能开干。但如果你遇到的是下面这些场景老项目锁定在GDAL 1.x系列、Qt用了MinGW工具链导致MSVC库没法混用、或者需要给一个叫libgdal-1.dll的旧库做兼容性封装那mingw64编译的GDAL 1.11.5几乎就是唯一解。GDAL 1.11.5是1.x系列的收官版本在2016年底发布之后整个1.x分支就停更了。按理说这种老版本早该被2.x、3.x替代但地理空间领域的老代码生命力超出想象。我自己就接过一个维护需求对方的GIS平台从32位迁移到64位原来的GDAL预编译包是x86的一连串依赖全部作废最后只能自己动手在mingw64环境下从源码完整编一套。这篇就顺着这条线把整个过程的决策逻辑、编译流程、踩坑点和集成方法写清楚给后面要干同样事的人省点时间。1. 为什么要折腾GDAL 1.11.5这种老古董1.1 GDAL 1.11.5的特殊定位GDAL 1.x和现在主流的2.x、3.x在很多核心API上并不是无缝兼容的。1.11.5的代码主体是C98风格很多老项目里大量使用GDALOpen这种C接口配合C封装来做二次开发函数签名、错误处理、甚至数据模型都和后来的版本有明显差异。尤其要注意的是2.x引入的GDALOpenEx、统一栅格/矢量API以及3.x对多线程模型的强化让老代码在升级时不是改两个函数名那么简单。很多生产系统里基于1.x做的格式插件、内存数据管理逻辑换到新版本后行为直接变了。所以一些对稳定性要求极高、又不想投入人力做迁移测试的团队宁可在新环境里继续用1.11.5也不愿意冒升级风险。1.2 什么场景会把人逼到源码编译这一步我自己遇到过的真实需求有几类你可以对号入座老项目的构建环境从32位迁移到64位原来下载的预编译GDAL只有x86版或者x64版对应的依赖库版本和项目不匹配。项目用了MinGW分支的Qt做桌面端开发GIS核心模块需要链接GDAL。这时候MSVC编译的GDAL就非常尴尬因为GCC和MSVC的导入库、运行时库、异常处理模型都不一致硬链接的结果通常是编译报错或者编译过了运行起来出诡异崩溃。第三方库或插件明确依赖GDAL 1.11.5的导出符号和ABI比如某些老版本的QGIS插件、收费GIS模块。自己维护的发行套件里捆绑了特定版本的GDAL为了保持所有环境行为一致不允许随便换版本。这一类需求基本都能在社区里搜到同类提问结论都是一样的用mingw64自己编而不是找现成包。1.3 为什么选择mingw64而不是MSVC的nmake方案GDAL官方在Windows平台上的构建方案最早是给MSVC准备的源码目录里就有nmake.opt和说明文档。但GDAL 1.x整体构建体系是Unix风格configure脚本、Makefile、gcc/g这一整套。用MSVC去编也不是不行但要额外处理很多环境变量和外部依赖而且最终产物是.lib导入库跟GCC系工具链基本绝缘。mingw64则完全踩在GCC生态上生成的libgdal.dll.a导入库可以直接让MinGW的GCC用Qt的MinGW版本、Code::Blocks自带的编译器、MSYS2里的各种开源库都能无缝衔接。说白了选择mingw64不是因为它比MSVC更好而是因为你的下游工具链是GCC系GDAL必须用同一套编译器来编译这是最容易被忽略的一环。2. 搭建mingw64环境依赖库选型决定后面的坑2.1 MSYS2与mingw64工具链在Windows上获得mingw64工具链最省事的方式是安装MSYS2。安装包从官网下载默认装到C:\msys64。装完后不要直接用Windows的cmd去编译GDAL 1.x的configure是shell脚本需要在MSYS2提供的MinGW64环境里运行。打开MSYS2 MinGW x64终端先做一轮更新和工具链安装pacman -Syu pacman -S --needed base-devel mingw-w64-x86_64-toolchainbase-devel会带来patch、make等基础工具mingw-w64-x86_64-toolchain则是完整的GCC工具链。注意必须是在MinGW64终端里因为只有这个终端的PATH默认包含了/mingw64/binconfigure脚本才能顺利找到gcc和make。2.2 依赖库哪些必须、哪些可以砍编译GDAL之前最难的不是主程序编译而是决定依赖库怎么配。依赖库选型直接决定你后面要踩多少坑我给你一个实际测试过的最小配置参考依赖库是否必须作用备注zlib必须TIFF/PNG等格式的压缩数据支持建议用pacman装mingw64版本libtiff强烈建议GeoTIFF读写核心没有它GDAL的栅格能力直接瘫痪libpng建议PNG格式支持处理遥感图像时很常用libjpeg-turbo建议JPEG格式支持同上proj视需求坐标投影转换GDAL 1.11.5需要老版本proj 4.9.x新版proj没有proj_api.h这个是最大的坑geos可选空间拓扑运算不需要OpenGIS几何运算就关闭curl可选WMS/WCS等远程数据源配置麻烦新项目基本用不上sqlite3可选GPKG等格式支持不需要可以关安装常用依赖库的命令pacman -S mingw-w64-x86_64-zlib \ mingw-w64-x86_64-libtiff \ mingw-w64-x86_64-libpng \ mingw-w64-x86_64-libjpeg-turbo \ mingw-w64-x86_64-expat这里有一个必须提前知道的常识所有依赖库都必须用mingw64版本不能用MSVC编译出来的版本。MSVC的.lib导入库在GCC面前就是一堆无法解析的符号就算把DLL硬塞给编译器也会在链接阶段报出漫山遍野的undefined reference。2.3 源码包的正确获取方式GDAL 1.11.5源码从官网历史版本目录就能拿到文件名是gdal-1.11.5.tar.gz大概几十MB解压到任意工作目录比如/c/src/gdal-1.11.5。我的建议是解压到C:\src这种短路径下尽量别放在C:\Program Files或带中文的目录里。GDAL 1.x的configure脚本对路径里的空格特别敏感轻则检查不到依赖库重则直接生成错误的Makefile这类问题排查起来非常折磨人。3. configure与makeGDAL 1.11.5核心编译流程3.1 理解老的构建系统逻辑GDAL 1.x的源码根目录里你会看到两个体系并存nmake.opt和nmakefile是给MSVC用的configure和GNUmakefile则是给Unix/MinGW环境用的。mingw64走的完全是后者。configure脚本会做环境探测检查系统架构、编译器、依赖库头文件和库文件位置把结果写入生成的GDALmake.opt和cpl_config.h。整个流程一旦出错不要急着重新跑先把最新报错信息定位到具体是哪个依赖检查环节失败这比无限重试有用得多。3.2 configure配置项每个参数的实际含义我实际使用的configure命令大致如下拆开讲解cd /c/src/gdal-1.11.5 ./configure --prefix/c/gdal-win64 \ --with-curlno \ --with-geosno \ --with-proj/c/proj-4.9.3-win64 \ --with-pythonno \ --without-libtool--prefix/c/gdal-win64安装路径根据前面说的避开空格原则设置。--with-curlno明确关闭远程数据源驱动避免configure去系统里反复查找curl库。如果你确实需要WMS等远程服务就另外用pacman装上mingw-w64-x86_64-curl再改成--with-curlyes。--with-geosno没有安装GEOS就关掉。GDAL 1.x对GEOS的依赖不只是头文件还涉及OGR几何函数的运行时交互没有把握不要开。--with-proj/c/proj-4.9.3-win64这里指向的是你额外编译安装的PROJ 4.9.x目录。如果你不需要坐标转换可以改成--with-projno但GIS项目基本绕不开投影我建议还是老老实实把老proj编出来。--with-pythonno关掉Python绑定因为我们只需要C/C库。OpenGDA官方对Python绑定的依赖比较啰嗦开了反而容易因为distutils版本问题卡住。--without-libtoolGDAL 1.x默认有可能尝试走libtool构建路径在MinGW环境下有时会生成动态库失败。不用libtool可以少一层麻烦不过也可能导致产物只有静态库具体看你需要的链接方式。3.3 make、安装与产物验证configure通过后直接编译make -j4-j4是四线程并行新手不建议给太高因为如果某个编译单元报错多线程的报错输出会混在一起很难定位。等第一次编译成功之后再考虑并行加速。整个编译时间取决于机器性能老机器可能二十分钟新机器几分钟就能跑完。编译完成后执行make install安装后的目录结构大致是这样include/gdal.h、gdal_priv.h、ogr_api.h、cpl_conv.h等头文件。lib/libgdal.a静态库和libgdal.dll.a导入库。bin/gdalinfo.exe、gdal_translate.exe、ogrinfo.exe等命令行工具以及GDAL主动态库和依赖库。验证一下基本功能/c/gdal-win64/bin/gdalinfo --version /c/gdal-win64/bin/gdalinfo --formats只要能看到GDAL 1.11.5, released 2016/...和一大票格式驱动列表核心编译就算完成了。4. 编译中高频踩坑proj头文件、混用产物、gcc版本4.1 proj 6.0以上移除了proj_api.hGDAL 1.11.5直接编译失败这是整个GDAL 1.x在mingw64下编译遇到最多的问题。PROJ库在6.0.0版本把老式的proj_api.h头文件和pj_init这套API全部移除了只保留基于PROJ类和proj.h的新接口。GDAL 1.11.5的代码里凡是用到坐标投影的模块都依赖proj_api.h。如果你从MSYS2的源直接安装新版projconfigure阶段也许能检测到libproj库但编译到对应文件时会直接报fatal error: proj_api.h: No such file or directory解决办法有两个推荐下载PROJ 4.9.3源码用同样的mingw64工具链编译并安装到独立目录比如/c/proj-4.9.3-win64然后传给GDAL的--with-proj参数。省事--with-projno牺牲所有投影转换能力。如果你做的是正儿八经的GIS开发我强烈建议别在图省事之后后悔。坐标转换在GDAL里牵扯太广很多格式驱动写进元数据时也会调用投影接口关掉proj会损失大量功能。4.2 依赖库混用MSVC产物引发的连锁反应有人会想proj库我直接找一个MSVC编译好的DLL来凑合用反正都是Windows。这个想法我劝你趁早打消。MSVC和MinGW的导入库格式不同pe导出符号机制也存在差异。MinGW的gcc链接器看到MSVC生成的.lib通常会报undefined reference to __imp_pj_init这种以__imp_开头的未定义符号就是GCC无法理解MSVC导入库的典型表现。就算个别库用dlltool能把DLL转成.a导入库ABI层面的C语言结构体对齐、__cdecl调用约定等细节也容易埋雷。实践原则只有一条GDAL的每一个依赖库都必须用mingw64编译不要混用任何MSVC产物。4.3 过新的gcc版本对老代码不友好MSYS2仓库里的mingw64工具链更新速度很快如果你装到了gcc 12甚至更高的版本编译GDAL 1.11.5时可能会碰到老代码在严格编译器下报错的情况。常见症状是某些默认警告被当成错误比如-Werror开启后老代码里的类型转换或未使用参数直接中断编译。遇到这种情况可以在configure时人为放宽编译选项./configure --prefix/c/gdal-win64 \ CFLAGS-O2 -Wno-error \ CXXFLAGS-O2 -Wno-error \ --with-curlno \ --with-proj/c/proj-4.9.3-win64如果已经编到一半报错不建议盲目加-fpermissive那是最后的逃生手段。更理性的做法是回去装一个gcc 9或10的旧版本确保工具链和源码属于同一个时代。以我给几个项目搭环境的经验看gcc 10在大多数情况下都能顺利编过1.11.5gcc 12开始才需要额外处理。4.4 路径、杀毒软件和其他隐蔽问题再补充几个经常把人逼疯的细节安装路径和源码路径都不能有空格C:\Program Files这种目录是configure脚本的重灾区。Windows自带的杀毒软件有可能在生成大量DLL时误报建议把MSYS2目录、源码目录、安装目录都加入白名单。不要在Windows cmd里直接敲./configure那不是cmd能解析的脚本必须在MSYS2 MinGW64终端里运行。如果你的依赖库是用pacman装在/mingw64下的configure通常能自动找到如果是自己编译安装到自定义目录最好用--with-xxx/路径明确指定否则configure检查通过但实际编译时找不到头文件的情况也会出现。5. 编译产物集成CMake链接、动态库部署与实际测试5.1 先做一轮冒烟测试编译安装完成后先用命令行工具做基础验证。找一张真实的GeoTIFF测试一下export PATH/c/gdal-win64/bin:$PATH gdalinfo /path/to/your/test.tif能正确输出影像大小、波段数、投影信息就说明GDAL核心驱动工作正常。ogrinfo再测一下矢量格式比如读一个ESRI Shapefile确认OGR模块也没问题。测试阶段不要急着用CSV之类的简单格式能覆盖GeoTIFF和Shapefile这种基础格式就足够暴露大多数问题。5.2 在CMake工程中集成GDALGDAL 1.11.5本身没有内建CMake config文件所以find_package(GDAL)依赖CMake自带的FindGDAL模块。这个模块老版本的习惯是优先找gdal-config程序。因此在CMake之前需要把C:\gdal-win64\bin加入PATH或者设置环境变量GDAL_ROOT让CMake能找到对应的可执行文件。一个常规的CMake集成写法find_package(GDAL REQUIRED) include_directories(${GDAL_INCLUDE_DIR}) target_link_libraries(myapp PRIVATE ${GDAL_LIBRARY})如果find_package还是找不到就直接手动指定路径set(GDAL_INCLUDE_DIR C:/gdal-win64/include) set(GDAL_LIBRARY C:/gdal-win64/lib/libgdal.dll.a)需要注意的是mingw下的GDAL导入库是libgdal.dll.a不是MSVC习惯的gdal_i.lib。如果你的构建脚本里写的-lgdalGCC会自动找到libgdal.dll.a或libgdal.a不需要额外改库名。5.3 写一个最小示例验证链接写一个读取栅格影像基本信息的C程序验证整条编译链是否通畅#include gdal_priv.h #include cstdio int main() { GDALAllRegister(); GDALDataset* ds static_castGDALDataset*( GDALOpen(C:/data/test.tif, GA_ReadOnly)); if (ds) { std::printf(size: %dx%d, bands: %d\n, ds-GetRasterXSize(), ds-GetRasterYSize(), ds-GetRasterCount()); GDALClose(ds); } else { std::printf(open failed\n); } return 0; }编译命令g -o read_img.exe read_img.cpp \ -I C:/gdal-win64/include \ -L C:/gdal-win64/lib -lgdal运行前确保C:\gdal-win64\bin在PATH里或者把GDAL主动态库和它依赖的proj、tiff等DLL全部拷到exe所在目录。如果运行时提示找不到DLL先不要怀疑代码直接在命令行里跑where gdal111.dll看路径是否可达。我个人在实际排查中最常用也最有效的工具是objdump -p read_img.exe | grep DLL Name一条命令就能列出程序依赖的动态库列表哪个缺失一目了然。这套编译流程走完再回头看整个过程最花时间的其实不是GDAL本身的编译而是把proj固定在4.9.x这个老版本上并且确保所有依赖库统一用mingw64编译。只要你记住这个顺序先统一工具链再解决依赖库最后回来编主库基本能少走一大半弯路。本文还有配套的精品资源点击获取