简介这份资源是作者在 Windows 下用 msys2 mingw64 方式预先编译好的 GDAL 1.11.5 库面向使用 QtMinGW 版做 C 桌面开发、需要处理 GIS 栅格与矢量数据的开发者省去自行搭建编译环境、处理依赖与链接错误的时间。压缩包共 149 个文件约 70.71MB以 63 个 h 头文件、22 个 exe 工具程序、28 个 csv 坐标与投影参数表为主另含 a 静态库、dll 动态库、gfs、wkt、xsd 等配置与模式文件覆盖开发头文件、运行库和配套数据。已有 1522 人学习下载。解压后将 bin 目录加入系统环境变量在 .pro 中配置 GDAL 即可调用作者还针对程序异常结束的情况给出了排错思路便于快速定位运行库缺失或路径问题适合希望跳过编译环节、直接进入功能验证与项目集成的开发者参考。1. 从一次编译翻车说起为什么 Mingw64 下装 GDAL 1.11.5 值得单独记一笔上周帮一个做桌面 GIS 的开发者收拾环境他要在 Windows 上用 Qt 接 GDAL 读矢量数据结果gdalinfo一跑就报找不到libgdal-1.dll换了个 MinGW 版本重新编译又卡在proj_api.h缺失。这类问题在 GDAL 1.11.5 加 MinGW-w64 的组合里特别常见——版本老、依赖链固定、编译器和 Qt 的 ABI 必须严丝合缝。这套环境适合两类人一是维护老项目的 C 开发者二是需要在 Qt 里嵌 GDAL 做数据转换的桌面端同学。装不好不会报一个清晰的错而是编译到一半缺头文件、链接期符号对不上或者运行时 DLL 加载失败排查成本很高。下面按我实际走通的顺序把版本、编译参数、Qt 接入和验证一次讲清。2. 装前把版本和依赖钉死MinGW-w64、Qt 与 GDAL 1.11.5 的对应关系GDAL 1.11.5 是 2015 年前后的版本它的构建系统还是 autotools 那一套没有 CMake 的现代支持。这意味着编译器、Qt 和第三方库的版本不能随手拿最新的往上套。我一般先把下面这张对照表写进项目 README后面谁接手都不至于装错。2.1 版本对照表与工具链选择组件推荐版本说明MinGW-w64GCC 4.9.2 / 5.3.0posix 线程seh 异常与 Qt 5.5/5.6 官方 MinGW 包一致避免 ABI 冲突Qt5.5.1 或 5.6.xMinGW 版必须和编译器同源别混用 MSVC 版 QtGDAL1.11.5 源码包用gdal-1.11.5.tar.gz不要拿 git masterPROJ4.9.xGDAL 1.11.5 依赖proj_api.hPROJ 5 之后接口变了GEOS3.5.x可选需要空间谓词时再编非必需这里最容易翻车的是 Qt 和 MinGW 的匹配。Qt 官方给的 MinGW 包自带编译器路径一般在Qt/Tools/mingw492_32或mingw530_32直接用它别去另下一个 MinGW 往 PATH 里塞。两个 MinGW 混用编译能过链接 Qt 库时会出现undefined reference to _Unwind_Resume这类玄学错误。2.2 环境变量与目录规划我习惯把源码和安装前缀分开避免污染系统目录# 假设工作根目录为 D:/gdal-build export SRC_ROOT/d/gdal-build/src export PREFIX/d/gdal-build/install export MINGW/d/Qt/Tools/mingw492_32 export PATH$MINGW/bin:$PATH # 验证编译器身份必须和 Qt 同源 gcc --version g --versionPREFIX是后面./configure --prefix的目标所有头文件、库、DLL 都会装到这里Qt 工程里只认这一个路径。PATH里把 MinGW 放最前是为了让configure找到正确的gcc。执行完gcc --version要确认输出里的版本号和 Qt 工具链目录名对得上对不上就先解决这个别往下走。提示Windows 下用 MSYS2 的 bash 跑 autotools 最省事但编译产物仍是 MinGW 目标不要用 MSYS2 自带的/usr/bin/gcc那是另一套运行时。3. 编译 GDAL 1.11.5configure 参数逐个说清源码包解压后进目录先跑一次./configure --help看有哪些开关。GDAL 1.11.5 的选项很多但真正影响 Qt 接入和体积的就那几个。我的原则是只开需要的驱动关掉用不上的编译时间和 DLL 体积都能降下来。3.1 configure 命令与参数取舍cd $SRC_ROOT/gdal-1.11.5 ./configure \ --prefix$PREFIX \ --hosti686-w64-mingw32 \ --with-threadsyes \ --without-libtool \ --with-proj$PREFIX \ --with-geos$PREFIX/bin/geos-config \ --without-python \ --without-curl \ --without-pg \ --without-mysql \ --without-odbc \ --disable-shared \ --enable-static逐条说--host指定交叉目标32 位 Qt 就写i686-w64-mingw3264 位写x86_64-w64-mingw32写错会导致库位数和 Qt 对不上。--with-proj指向前面装好的 PROJ 前缀GDAL 靠它找proj_api.h。--without-libtool在 MinGW 下能少一层包装DLL 导出更干净。--disable-shared --enable-static是我在 Qt 桌面项目里的偏好静态链 GDAL运行时少一个 DLL 依赖代价是最终 exe 变大。如果你要多个程序共用 GDAL改成--enable-shared更合适。--without-python一定要加GDAL 1.11.5 的 Python 绑定在 MinGW 下基本编不过留着只会让 configure 阶段报错。数据库驱动按需关桌面读文件场景用不到 PostgreSQL 和 MySQL。3.2 编译与安装make -j4 make install-j4按 CPU 核数调老机器给-j2更稳。编译过程中如果报某个驱动缺头文件回到 configure 加--without-xxx关掉它别去补装依赖——1.11.5 的驱动太多全开不现实。make install完成后检查$PREFIX下是否有include/gdal.h、lib/libgdal.a或bin/libgdal-1.dll有就说明主体装好了。注意如果 configure 报checking for proj_api.h... no先确认$PREFIX/include/proj_api.h存在再确认--with-proj路径没写错。PROJ 自己也要用同一个 MinGW 编混编一样会失败。4. 把 GDAL 接进 Qt 工程.pro 写法与运行时 DLL 处理编译装好只是第一步Qt 工程能不能正确链接、运行时能不能找到 DLL是另一道坎。我见过太多人编译过了一跑就弹「无法定位程序输入点」。4.1 .pro 文件配置# 假设 GDAL 装在 D:/gdal-build/install GDAL_PREFIX D:/gdal-build/install INCLUDEPATH $$GDAL_PREFIX/include LIBS -L$$GDAL_PREFIX/lib -lgdal # 静态链接时还需要这些系统库 win32: LIBS -lws2_32 -lole32 -luuid -lcomdlg32INCLUDEPATH指向gdal.h所在目录LIBS里的-lgdal对应libgdal.a或libgdal.dll.a。静态链接时GDAL 内部用到了 Windows 的 socket、COM 和 UUID 接口必须补上-lws2_32 -lole32 -luuid否则链接期会报一堆undefined reference。这几个库的顺序也有讲究放在-lgdal后面链接器从左到右解析符号。4.2 运行时 DLL 与插件目录如果用的是动态库libgdal-1.dll必须和 exe 同目录或者放进 PATH。GDAL 还有一套驱动插件机制GDAL_DRIVER_PATH环境变量指向$PREFIX/lib/gdalplugins不设的话部分格式读不了。我一般在main()开头加一句qputenv(GDAL_DRIVER_PATH, D:/gdal-build/install/lib/gdalplugins); GDALAllRegister();GDALAllRegister()是必须调的不调的话GDALOpen返回空很多人以为是路径问题其实是忘了注册驱动。qputenv在 Qt 里设置环境变量比改系统环境变量干净换机器只改一处。5. 避坑记录MinGW 编 GDAL 1.11.5 最常见的五个坑5.1 现象configure 报proj_api.h找不到原因PROJ 没装或装到了别的编译器前缀下。解决用同一个 MinGW 先编 PROJ 4.9.x./configure --prefix$PREFIX后make install再回来编 GDAL。别用预编译的 PROJ 包位数和运行时经常对不上。5.2 现象链接期大量undefined reference to _imp__...原因动态库和静态库混用或者-lgdal找到了错误的.dll.a。解决清掉$PREFIX/lib下多余的libgdal.dll.a只留libgdal.a确认.pro里没有同时出现-lgdal和手动指定的 DLL。5.3 现象程序启动弹「找不到 libgdal-1.dll」原因动态链接但 DLL 不在搜索路径。解决把$PREFIX/bin/libgdal-1.dll拷到 exe 同目录或用windeployqt之后手动补。静态链接可以彻底绕开这个问题代价是 exe 体积。5.4 现象GDALOpen返回 NULL文件明明存在原因忘了GDALAllRegister()或GDAL_DRIVER_PATH没设导致插件驱动没加载。解决在main()里先注册再打开路径用绝对路径别用相对路径试。5.5 现象编译到某个驱动时报缺sqlite3.h之类原因configure 自动探测到了系统里的半套依赖。解决回到 configure 加--without-sqlite3或对应驱动开关重跑不要临时去补装库1.11.5 的依赖树补不干净。6. 装完怎么验证三步确认这套 GDAL 真的能用验证不能只看「编译通过」要分三层命令行工具、库链接、Qt 运行时。我一般按下面顺序走一遍任何一步不过就回到对应章节。第一步命令行验证。$PREFIX/bin下应该有gdalinfo.exe跑$PREFIX/bin/gdalinfo --version # 期望输出GDAL 1.11.5, released 2016/04/30版本号对得上说明主体库和驱动注册没问题。再拿一个小的 shapefile 或 GeoTIFF 跑gdalinfo 文件名能打出图层信息就说明数据驱动正常。第二步链接验证。写一个最小 Qt 控制台工程只调GDALVersionInfo(RELEASE_NAME)并打印.pro按第 4 章配置。能编译、能运行、输出1.11.5说明头文件路径和库路径都对。第三步运行时验证。在 Qt 里打开一个真实数据源GDALAllRegister(); GDALDataset* ds (GDALDataset*)GDALOpen(D:/data/test.shp, GA_ReadOnly); if (ds) { qDebug() layers: ds-GetLayerCount(); GDALClose(ds); } else { qDebug() open failed: CPLGetLastErrorMsg(); }CPLGetLastErrorMsg()是关键打开失败时它会给出具体原因比盲猜强得多。三步都过这套环境才算真正跑通。从那以后我每次配 GDAL 加 Qt 的环境都强制先跑一遍gdalinfo --version再动工程文件版本不对就停手绝不带着半套环境往下写代码。希望帮到你。本文还有配套的精品资源点击获取