尧图网站建设 
简介本资源为在Windows平台下基于msys2与MinGW32工具链预先编译完成的GDAL 1.11.5开发库面向使用QtMinGW版进行地理空间数据处理开发的程序员可省去自行编译GDAL的繁琐过程。压缩包共149个文件约74.73MB包含63个C/C头文件、22个可执行工具、2个静态库及1个动态库另附大量CSV坐标与投影参数数据、WKT、GFS、XSD等GIS配置资源覆盖编译、链接与运行所需的核心组件。解压后将bin目录加入系统环境变量并在.pro文件中配置GDAL路径即可直接调用。目前已有779人学习下载适合需要快速搭建GDALQt开发环境、专注业务逻辑而非编译排错的开发者参考使用。1. GDAL 1.11.5 配 mingw32一个被低估的 Windows 编译组合如果你在 Windows 上做 GIS 二次开发大概率绕不开 GDAL。但当你翻到某个老项目的构建脚本看到GDAL 1.11.5和mingw32这两个词摆在一起时心里多半会咯噔一下——这版本太老了老到官方早就停止维护老到很多依赖库的下载链接都变成了 404。可现实是仍有不少存量系统、嵌入式采集设备、甚至某些行业软件的数据处理模块就锁死在这个组合上。你没法升级因为升级意味着整条工具链重来你也没法绕开因为数据格式的读写就靠它。这篇文章要解决的就是怎么在 Windows 上把 GDAL 1.11.5 用 mingw32 工具链编出来、跑起来、并且能稳定读写常见栅格与矢量格式。适合两类人一是接手了老项目、必须复现当年构建环境的工程师二是想理解 GDAL 在 Windows 下编译机制、顺便把 mingw32 这套轻量工具链用熟的技术人。我不会只给你一条configure命令就完事而是把依赖怎么凑、参数怎么设、编译报错怎么查一步步拆开讲。2. 为什么是 mingw32 而不是 MSVC选型背后的真实考量2.1 mingw32 与 MSVC 在 GDAL 编译上的核心差异在 Windows 上编 GDAL绝大多数教程会告诉你用 Visual Studio。这没错MSVC 对 Windows API 的支持最完整调试信息也最友好。但 GDAL 1.11.5 这个年代的代码大量使用了 C99 特性而老版本 MSVC 对 C99 的支持是残缺的。mingw32 基于 GCC天生支持 C99编译 GDAL 源码时少了很多语法层面的糟心事。另一个关键点是依赖库的获取方式。MSVC 下你通常需要自己用 CMake 逐个编译 PROJ、GEOS、libtiff、libpng 等一长串依赖每个库的版本兼容性都要手动对齐。而 mingw32 环境里很多基础库可以通过 MSYS2 的包管理器直接装省去大量交叉编译的麻烦。当然代价是最终产物的运行时要带上libgcc_s_seh-1.dll、libstdc-6.dll这些 GCC 运行时部署时得多拷几个文件。还有一个容易被忽略的点GDAL 1.11.5 的configure脚本对 mingw32 有专门的分支判断。源码里configure会检测mingw32主机三元组并自动调整一些编译选项比如禁用某些不兼容的 POSIX 调用。这意味着用 mingw32 编译时你踩的坑会少一些——至少不会遇到 MSVC 下那种“链接器找不到符号”的玄学问题。2.2 工具链准备MSYS2 mingw-w64 32 位环境搭建我一般用 MSYS2 来搭这个环境因为它同时提供了包管理和完整的 GCC 工具链。注意这里要的是 32 位目标所以装的是mingw-w64-i686系列包而不是x86_64。第一步从 MSYS2 官网下载安装包装完后打开 MSYS2 MinGW 32-bit 终端。这个终端会自动把/mingw32/bin加进 PATH后续所有命令都在这个终端里执行。# 更新包数据库和基础包 pacman -Syu # 如果提示关闭终端重新打开就照做然后继续 pacman -Su # 安装 32 位 GCC 工具链和基础开发库 pacman -S mingw-w64-i686-gcc \ mingw-w64-i686-make \ mingw-w64-i686-pkg-config \ mingw-w64-i686-zlib \ mingw-w64-i686-libpng \ mingw-w64-i686-libjpeg-turbo \ mingw-w64-i686-libtiff \ mingw-w64-i686-libgeotiff这几条命令装完后gcc --version应该显示i686-w64-mingw32目标。pkg-config --list-all能看到 zlib、libpng 等库的.pc文件这是后续configure能找到依赖的关键。注意不要混用 MSYS 终端和 MinGW 终端。MSYS 终端里的 GCC 是给 MSYS 自身用的编出来的东西依赖msys-2.0.dll不是我们要的原生 Windows 程序。2.3 GDAL 1.11.5 源码获取与目录结构确认GDAL 1.11.5 的源码包在官方归档里还能找到文件名通常是gdal-1.11.5.tar.gz。下载后解压到一个不含空格和中文的路径比如D:/build/gdal-1.11.5。解压后目录里应该有configure、Makefile.in、gcore、frmts、ogr这些子目录。进到源码根目录先跑一次./configure --help确认脚本能正常执行。如果报/bin/sh^M: bad interpreter说明源码包在 Windows 下被改过换行符用dos2unix configure转一下就行。这一步看似简单但很多编译失败就卡在这里——脚本根本跑不起来后面的一切都无从谈起。3. 从 configure 到 makeGDAL 1.11.5 的完整编译流程3.1 configure 参数逐项拆解与推荐配置GDAL 的configure脚本参数很多但真正影响 mingw32 编译成败的就那么几个。下面是我在 32 位环境下反复验证过的一套配置./configure \ --hosti686-w64-mingw32 \ --prefix/d/build/gdal-install \ --with-pnginternal \ --with-jpeginternal \ --with-libtiffinternal \ --with-geotiffinternal \ --with-zlibinternal \ --without-python \ --without-curl \ --without-sqlite3 \ --without-pg \ --without-mysql \ --disable-shared \ --enable-static逐项说明--hosti686-w64-mingw32告诉 configure 目标平台是 32 位 Windows这是 mingw32 编译的核心标识。--prefix安装路径用 MSYS2 风格的路径写法不要用D:\build\...这种反斜杠格式。--with-*internal让 GDAL 使用自带的内部库来编 PNG、JPEG、TIFF、GeoTIFF、zlib。这是最省事的做法避免外部库版本不匹配导致的链接错误。代价是编出来的库体积稍大但功能完整。--without-pythonGDAL 1.11.5 的 Python 绑定对 Python 2.x 依赖很重在 mingw32 下编 Python 绑定几乎必然翻车直接关掉。--without-curl、--without-sqlite3、--without-pg、--without-mysql这些是网络和数据库驱动除非你明确需要否则关掉能大幅减少依赖问题和编译时间。--disable-shared --enable-static只编静态库。如果你需要 DLL把这两行换成--enable-shared --disable-static但要注意 DLL 的导出符号问题后面避坑章节会讲。configure 跑完后终端最后会输出一个摘要列出哪些驱动被启用、哪些被禁用。仔细看一遍确认你需要的格式比如 GTiff、HFA、JPEG、PNG都在启用列表里。3.2 make 编译中的并行度与内存控制configure 成功后直接make就行。但 GDAL 1.11.5 的 Makefile 在并行编译时有个老问题某些子目录的依赖关系没写全make -j8可能会在编译到frmts目录时突然报“找不到某个头文件”。这不是代码错误而是并行调度导致的顺序问题。我的做法是分两步# 先串行编译核心库确保依赖顺序正确 make -j1 # 如果串行编译通过再清理后并行编译加速 make clean make -j4如果机器内存小于 8GB-j4就够了再高容易触发 OOM。编译过程中如果看到某个.cpp文件卡住超过两分钟大概率是模板实例化爆炸可以 CtrlC 中断单独进到那个子目录用make重试。编译完成后make install会把头文件、静态库、可执行文件拷到--prefix指定的目录。检查一下lib目录下有没有libgdal.abin目录下有没有gdalinfo.exe。如果gdalinfo.exe存在但运行时报“缺少 libgcc_s_seh-1.dll”说明运行时库没拷过去手动从/mingw32/bin复制这几个 DLL 到bin目录即可。3.3 验证编译产物gdalinfo 与格式支持检查编完不验证等于白编。最直接的验证方式是跑gdalinfo --formats看输出里有没有你需要的格式驱动。# 进入安装目录的 bin 文件夹 cd /d/build/gdal-install/bin # 列出所有支持的格式 ./gdalinfo --formats # 查看版本信息 ./gdalinfo --version--version应该输出GDAL 1.11.5, released 2016/01/26。--formats的输出是一个长列表每一行格式名后面跟着rw表示支持读写r表示只读。重点确认GTiff、PNG、JPEG、HFA、ESRI Shapefile这几个常用格式的状态。如果某个格式显示为r而不是rw说明对应的写支持没编进去通常是configure时那个库被禁用了。回到 configure 步骤检查对应--with-*参数。提示gdalinfo本身也是一个很好的调试工具。拿一个实际的 TIFF 或 Shapefile 文件跑一下gdalinfo yourfile.tif如果能正常输出坐标系、波段数、范围信息说明核心功能没问题。4. 避坑指南mingw32 编译 GDAL 1.11.5 的五个血泪教训4.1 现象configure 报 “C compiler cannot create executables”原因MSYS2 的 MinGW 32-bit 终端没装全或者 PATH 里混入了 MSYS 的 GCC。最常见的情况是用户从开始菜单打开了 “MSYS2 MSYS” 而不是 “MSYS2 MinGW 32-bit”。解决关掉当前终端从开始菜单明确选择 “MSYS2 MinGW 32-bit”。执行which gcc确认输出是/mingw32/bin/gcc而不是/usr/bin/gcc。如果还是不对手动export PATH/mingw32/bin:$PATH再试。4.2 现象链接时大量 “undefined reference to__imp_xxx”原因这是 Windows 下动态链接库的符号导入问题。当你用--enable-shared编 DLL 时GDAL 内部某些函数没有加__declspec(dllexport)导致链接器找不到符号。解决最省事的办法是改用静态库编译也就是--disable-shared --enable-static。如果必须出 DLL需要在编译前给gcore/gdal_priv.h等头文件手动加导出宏或者用.def文件显式导出符号。后者工作量大非必要不推荐。4.3 现象编译到ogr/ogrsf_frmts目录时卡死或报内存不足原因OGR 的驱动目录下有很多自动生成的代码单个.cpp文件展开后极大GCC 在 32 位模式下地址空间有限容易 OOM。解决不要用-j并行编译这个目录。先cd ogr/ogrsf_frmts然后make -j1单独编。如果还是内存不足给 GCC 加-O1降低优化级别或者用ulimit -v限制虚拟内存后重试。4.4 现象gdalinfo 能跑但读某些 TIFF 文件时报 “not recognized as a supported file format”原因GDAL 1.11.5 内部自带的 libtiff 版本较老不支持某些新式压缩如 LZMA、ZSTD或 BigTIFF 的某些变体。解决确认configure时用了--with-libtiffinternal。如果文件确实用了新压缩只能换用外部更新的 libtiff 重新编译或者用其他工具先转成普通 TIFF。这是版本本身的限制没有绕过的方法。4.5 现象编译成功但生成的 Shapefile 在 ArcGIS 里打开乱码原因GDAL 1.11.5 默认用 UTF-8 编码写 DBF 文件而某些老版本 ArcGIS 期望的是本地代码页如 GBK。解决在写 Shapefile 时设置SHAPE_ENCODINGGBK环境变量或者在代码里用OGRLayer::SetMetadataItem(ENCODING, GBK)。注意这个设置只影响 DBF 的字符字段不影响几何数据。5. 进阶技巧用 pkg-config 把 GDAL 1.11.5 集成到你的项目编好的 GDAL 最终是要被业务代码调用的。在 mingw32 环境下最干净的集成方式是用pkg-config。make install之后--prefix/lib/pkgconfig目录下会生成gdal.pc文件。把这个路径加进PKG_CONFIG_PATH编译时就能自动拿到头文件路径和链接参数。# 把 GDAL 的 pkg-config 路径加入环境变量 export PKG_CONFIG_PATH/d/build/gdal-install/lib/pkgconfig:$PKG_CONFIG_PATH # 验证 pkg-config 能否找到 gdal pkg-config --modversion gdal # 应输出 1.11.5 pkg-config --cflags gdal # 输出头文件包含路径 pkg-config --libs gdal # 输出链接参数包括 -lgdal 和依赖库在你的项目 Makefile 里这样写就能自动适配CFLAGS $(shell pkg-config --cflags gdal) LIBS $(shell pkg-config --libs gdal) your_program: your_program.o $(CC) -o $ $^ $(LIBS)如果链接时提示找不到-lgdal检查gdal.pc里的libdir是否指向了正确的lib目录。有时候make install会把静态库放在lib下但gdal.pc里写的是lib64手动改一下就行。另一个实用技巧是静态链接时的库顺序。GCC 链接静态库时对顺序敏感-lgdal必须放在所有依赖库之前。如果pkg-config --libs gdal输出的顺序不对手动调整成-lgdal -ltiff -ljpeg -lpng -lz这样的顺序。最后说一个我自己的习惯每次编完 GDAL我都会把gdalinfo.exe、gdal_translate.exe和那几个运行时 DLL 单独拷到一个tools文件夹里和业务程序放在一起。这样部署到客户机器上时不用装 MSYS2也不用配环境变量直接双击就能跑。这个习惯帮我省了无数次“在我机器上好好的”的扯皮。希望帮到你。本文还有配套的精品资源点击获取 GDAL 1.11.5 mingw32 Windows 编译实战：从 configure 到 gdalinfo 验证
简介本资源为在Windows平台下基于msys2与MinGW32工具链预先编译完成的GDAL 1.11.5开发库面向使用QtMinGW版进行地理空间数据处理开发的程序员可省去自行编译GDAL的繁琐过程。压缩包共149个文件约74.73MB包含63个C/C头文件、22个可执行工具、2个静态库及1个动态库另附大量CSV坐标与投影参数数据、WKT、GFS、XSD等GIS配置资源覆盖编译、链接与运行所需的核心组件。解压后将bin目录加入系统环境变量并在.pro文件中配置GDAL路径即可直接调用。目前已有779人学习下载适合需要快速搭建GDALQt开发环境、专注业务逻辑而非编译排错的开发者参考使用。1. GDAL 1.11.5 配 mingw32一个被低估的 Windows 编译组合如果你在 Windows 上做 GIS 二次开发大概率绕不开 GDAL。但当你翻到某个老项目的构建脚本看到GDAL 1.11.5和mingw32这两个词摆在一起时心里多半会咯噔一下——这版本太老了老到官方早就停止维护老到很多依赖库的下载链接都变成了 404。可现实是仍有不少存量系统、嵌入式采集设备、甚至某些行业软件的数据处理模块就锁死在这个组合上。你没法升级因为升级意味着整条工具链重来你也没法绕开因为数据格式的读写就靠它。这篇文章要解决的就是怎么在 Windows 上把 GDAL 1.11.5 用 mingw32 工具链编出来、跑起来、并且能稳定读写常见栅格与矢量格式。适合两类人一是接手了老项目、必须复现当年构建环境的工程师二是想理解 GDAL 在 Windows 下编译机制、顺便把 mingw32 这套轻量工具链用熟的技术人。我不会只给你一条configure命令就完事而是把依赖怎么凑、参数怎么设、编译报错怎么查一步步拆开讲。2. 为什么是 mingw32 而不是 MSVC选型背后的真实考量2.1 mingw32 与 MSVC 在 GDAL 编译上的核心差异在 Windows 上编 GDAL绝大多数教程会告诉你用 Visual Studio。这没错MSVC 对 Windows API 的支持最完整调试信息也最友好。但 GDAL 1.11.5 这个年代的代码大量使用了 C99 特性而老版本 MSVC 对 C99 的支持是残缺的。mingw32 基于 GCC天生支持 C99编译 GDAL 源码时少了很多语法层面的糟心事。另一个关键点是依赖库的获取方式。MSVC 下你通常需要自己用 CMake 逐个编译 PROJ、GEOS、libtiff、libpng 等一长串依赖每个库的版本兼容性都要手动对齐。而 mingw32 环境里很多基础库可以通过 MSYS2 的包管理器直接装省去大量交叉编译的麻烦。当然代价是最终产物的运行时要带上libgcc_s_seh-1.dll、libstdc-6.dll这些 GCC 运行时部署时得多拷几个文件。还有一个容易被忽略的点GDAL 1.11.5 的configure脚本对 mingw32 有专门的分支判断。源码里configure会检测mingw32主机三元组并自动调整一些编译选项比如禁用某些不兼容的 POSIX 调用。这意味着用 mingw32 编译时你踩的坑会少一些——至少不会遇到 MSVC 下那种“链接器找不到符号”的玄学问题。2.2 工具链准备MSYS2 mingw-w64 32 位环境搭建我一般用 MSYS2 来搭这个环境因为它同时提供了包管理和完整的 GCC 工具链。注意这里要的是 32 位目标所以装的是mingw-w64-i686系列包而不是x86_64。第一步从 MSYS2 官网下载安装包装完后打开 MSYS2 MinGW 32-bit 终端。这个终端会自动把/mingw32/bin加进 PATH后续所有命令都在这个终端里执行。# 更新包数据库和基础包 pacman -Syu # 如果提示关闭终端重新打开就照做然后继续 pacman -Su # 安装 32 位 GCC 工具链和基础开发库 pacman -S mingw-w64-i686-gcc \ mingw-w64-i686-make \ mingw-w64-i686-pkg-config \ mingw-w64-i686-zlib \ mingw-w64-i686-libpng \ mingw-w64-i686-libjpeg-turbo \ mingw-w64-i686-libtiff \ mingw-w64-i686-libgeotiff这几条命令装完后gcc --version应该显示i686-w64-mingw32目标。pkg-config --list-all能看到 zlib、libpng 等库的.pc文件这是后续configure能找到依赖的关键。注意不要混用 MSYS 终端和 MinGW 终端。MSYS 终端里的 GCC 是给 MSYS 自身用的编出来的东西依赖msys-2.0.dll不是我们要的原生 Windows 程序。2.3 GDAL 1.11.5 源码获取与目录结构确认GDAL 1.11.5 的源码包在官方归档里还能找到文件名通常是gdal-1.11.5.tar.gz。下载后解压到一个不含空格和中文的路径比如D:/build/gdal-1.11.5。解压后目录里应该有configure、Makefile.in、gcore、frmts、ogr这些子目录。进到源码根目录先跑一次./configure --help确认脚本能正常执行。如果报/bin/sh^M: bad interpreter说明源码包在 Windows 下被改过换行符用dos2unix configure转一下就行。这一步看似简单但很多编译失败就卡在这里——脚本根本跑不起来后面的一切都无从谈起。3. 从 configure 到 makeGDAL 1.11.5 的完整编译流程3.1 configure 参数逐项拆解与推荐配置GDAL 的configure脚本参数很多但真正影响 mingw32 编译成败的就那么几个。下面是我在 32 位环境下反复验证过的一套配置./configure \ --hosti686-w64-mingw32 \ --prefix/d/build/gdal-install \ --with-pnginternal \ --with-jpeginternal \ --with-libtiffinternal \ --with-geotiffinternal \ --with-zlibinternal \ --without-python \ --without-curl \ --without-sqlite3 \ --without-pg \ --without-mysql \ --disable-shared \ --enable-static逐项说明--hosti686-w64-mingw32告诉 configure 目标平台是 32 位 Windows这是 mingw32 编译的核心标识。--prefix安装路径用 MSYS2 风格的路径写法不要用D:\build\...这种反斜杠格式。--with-*internal让 GDAL 使用自带的内部库来编 PNG、JPEG、TIFF、GeoTIFF、zlib。这是最省事的做法避免外部库版本不匹配导致的链接错误。代价是编出来的库体积稍大但功能完整。--without-pythonGDAL 1.11.5 的 Python 绑定对 Python 2.x 依赖很重在 mingw32 下编 Python 绑定几乎必然翻车直接关掉。--without-curl、--without-sqlite3、--without-pg、--without-mysql这些是网络和数据库驱动除非你明确需要否则关掉能大幅减少依赖问题和编译时间。--disable-shared --enable-static只编静态库。如果你需要 DLL把这两行换成--enable-shared --disable-static但要注意 DLL 的导出符号问题后面避坑章节会讲。configure 跑完后终端最后会输出一个摘要列出哪些驱动被启用、哪些被禁用。仔细看一遍确认你需要的格式比如 GTiff、HFA、JPEG、PNG都在启用列表里。3.2 make 编译中的并行度与内存控制configure 成功后直接make就行。但 GDAL 1.11.5 的 Makefile 在并行编译时有个老问题某些子目录的依赖关系没写全make -j8可能会在编译到frmts目录时突然报“找不到某个头文件”。这不是代码错误而是并行调度导致的顺序问题。我的做法是分两步# 先串行编译核心库确保依赖顺序正确 make -j1 # 如果串行编译通过再清理后并行编译加速 make clean make -j4如果机器内存小于 8GB-j4就够了再高容易触发 OOM。编译过程中如果看到某个.cpp文件卡住超过两分钟大概率是模板实例化爆炸可以 CtrlC 中断单独进到那个子目录用make重试。编译完成后make install会把头文件、静态库、可执行文件拷到--prefix指定的目录。检查一下lib目录下有没有libgdal.abin目录下有没有gdalinfo.exe。如果gdalinfo.exe存在但运行时报“缺少 libgcc_s_seh-1.dll”说明运行时库没拷过去手动从/mingw32/bin复制这几个 DLL 到bin目录即可。3.3 验证编译产物gdalinfo 与格式支持检查编完不验证等于白编。最直接的验证方式是跑gdalinfo --formats看输出里有没有你需要的格式驱动。# 进入安装目录的 bin 文件夹 cd /d/build/gdal-install/bin # 列出所有支持的格式 ./gdalinfo --formats # 查看版本信息 ./gdalinfo --version--version应该输出GDAL 1.11.5, released 2016/01/26。--formats的输出是一个长列表每一行格式名后面跟着rw表示支持读写r表示只读。重点确认GTiff、PNG、JPEG、HFA、ESRI Shapefile这几个常用格式的状态。如果某个格式显示为r而不是rw说明对应的写支持没编进去通常是configure时那个库被禁用了。回到 configure 步骤检查对应--with-*参数。提示gdalinfo本身也是一个很好的调试工具。拿一个实际的 TIFF 或 Shapefile 文件跑一下gdalinfo yourfile.tif如果能正常输出坐标系、波段数、范围信息说明核心功能没问题。4. 避坑指南mingw32 编译 GDAL 1.11.5 的五个血泪教训4.1 现象configure 报 “C compiler cannot create executables”原因MSYS2 的 MinGW 32-bit 终端没装全或者 PATH 里混入了 MSYS 的 GCC。最常见的情况是用户从开始菜单打开了 “MSYS2 MSYS” 而不是 “MSYS2 MinGW 32-bit”。解决关掉当前终端从开始菜单明确选择 “MSYS2 MinGW 32-bit”。执行which gcc确认输出是/mingw32/bin/gcc而不是/usr/bin/gcc。如果还是不对手动export PATH/mingw32/bin:$PATH再试。4.2 现象链接时大量 “undefined reference to__imp_xxx”原因这是 Windows 下动态链接库的符号导入问题。当你用--enable-shared编 DLL 时GDAL 内部某些函数没有加__declspec(dllexport)导致链接器找不到符号。解决最省事的办法是改用静态库编译也就是--disable-shared --enable-static。如果必须出 DLL需要在编译前给gcore/gdal_priv.h等头文件手动加导出宏或者用.def文件显式导出符号。后者工作量大非必要不推荐。4.3 现象编译到ogr/ogrsf_frmts目录时卡死或报内存不足原因OGR 的驱动目录下有很多自动生成的代码单个.cpp文件展开后极大GCC 在 32 位模式下地址空间有限容易 OOM。解决不要用-j并行编译这个目录。先cd ogr/ogrsf_frmts然后make -j1单独编。如果还是内存不足给 GCC 加-O1降低优化级别或者用ulimit -v限制虚拟内存后重试。4.4 现象gdalinfo 能跑但读某些 TIFF 文件时报 “not recognized as a supported file format”原因GDAL 1.11.5 内部自带的 libtiff 版本较老不支持某些新式压缩如 LZMA、ZSTD或 BigTIFF 的某些变体。解决确认configure时用了--with-libtiffinternal。如果文件确实用了新压缩只能换用外部更新的 libtiff 重新编译或者用其他工具先转成普通 TIFF。这是版本本身的限制没有绕过的方法。4.5 现象编译成功但生成的 Shapefile 在 ArcGIS 里打开乱码原因GDAL 1.11.5 默认用 UTF-8 编码写 DBF 文件而某些老版本 ArcGIS 期望的是本地代码页如 GBK。解决在写 Shapefile 时设置SHAPE_ENCODINGGBK环境变量或者在代码里用OGRLayer::SetMetadataItem(ENCODING, GBK)。注意这个设置只影响 DBF 的字符字段不影响几何数据。5. 进阶技巧用 pkg-config 把 GDAL 1.11.5 集成到你的项目编好的 GDAL 最终是要被业务代码调用的。在 mingw32 环境下最干净的集成方式是用pkg-config。make install之后--prefix/lib/pkgconfig目录下会生成gdal.pc文件。把这个路径加进PKG_CONFIG_PATH编译时就能自动拿到头文件路径和链接参数。# 把 GDAL 的 pkg-config 路径加入环境变量 export PKG_CONFIG_PATH/d/build/gdal-install/lib/pkgconfig:$PKG_CONFIG_PATH # 验证 pkg-config 能否找到 gdal pkg-config --modversion gdal # 应输出 1.11.5 pkg-config --cflags gdal # 输出头文件包含路径 pkg-config --libs gdal # 输出链接参数包括 -lgdal 和依赖库在你的项目 Makefile 里这样写就能自动适配CFLAGS $(shell pkg-config --cflags gdal) LIBS $(shell pkg-config --libs gdal) your_program: your_program.o $(CC) -o $ $^ $(LIBS)如果链接时提示找不到-lgdal检查gdal.pc里的libdir是否指向了正确的lib目录。有时候make install会把静态库放在lib下但gdal.pc里写的是lib64手动改一下就行。另一个实用技巧是静态链接时的库顺序。GCC 链接静态库时对顺序敏感-lgdal必须放在所有依赖库之前。如果pkg-config --libs gdal输出的顺序不对手动调整成-lgdal -ltiff -ljpeg -lpng -lz这样的顺序。最后说一个我自己的习惯每次编完 GDAL我都会把gdalinfo.exe、gdal_translate.exe和那几个运行时 DLL 单独拷到一个tools文件夹里和业务程序放在一起。这样部署到客户机器上时不用装 MSYS2也不用配环境变量直接双击就能跑。这个习惯帮我省了无数次“在我机器上好好的”的扯皮。希望帮到你。本文还有配套的精品资源点击获取