企业官网建设流程全解析

简介：这是一份面向 C++ 开发者的 GDAL 3.5.3 x64 Release 预编译库资源，基于 VS2019 从多个开源依赖源码编译打包而成，可直接用于地理空间栅格与矢量的读写转换、投影处理等开发场景，免去自行配置编译环境、逐个组件构建的繁琐过程。压缩包共包含 905 个文件，整体大小约 110.93 兆字节，其中以 612 个头文件为主体，并配有导入库文件、动态链接库、命令行可执行程序、CMake 配置片段及若干数据与格式定义文件，内容覆盖从编译到集成所需的主要文件类别。内部依赖对应清晰：curl、PROJ、GEOS、SQLite、TIFF 等组件的版本均有明确说明，编译产物与源码版本互相匹配，可帮助使用者规避不同库版本混用的兼容性风险。此外还包含手册说明页、坐标参考定义等配套文件，便于查阅具体子模块的用法与参数含义；此包已有 204 人学习/下载，适合需要快速获得可用 GDAL 库、同时兼顾编译组合完整性的 C++ 开发者。

1. GDAL源码编译：为什么3.5.3还要从VS2019源码走一遭

做GIS二次开发的人拿到GDAL通常有两条路：一条是找现成的预编译包直接配进VS2019工程，另一条是从源码按自己依赖树编一套。预编译包的坑在于它背后的DLL组合是别人定死的，可能带着老版本PROJ、缺了curl、甚至在GeoTIFF驱动上根本没启用外部libtiff，运行期出问题根本无从排查。这次整理的是用VS2019从源码编译GDAL 3.5.3 x64-release库文件的完整过程，前置依赖包括sqlite、geos、PROJ、curl、tiff，每个都用源码方式编译，再把产物规整到统一目录，方便C++工程直接引用。适合需要精确控制坐标转换、栅格驱动和网络数据源行为的开发者。文章里的编译命令都是实际走通过的，版本号和路径按自己机器替换即可。

2. GDAL 3.5.3的依赖体系：先理清编译顺序，再动手不返工

2.1 GDAL 3.5.x为什么离不开外部依赖

GDAL的定位是栅格与矢量数据的统一抽象层，但它并不把所有格式都写死在内部，而是通过一组外部库去支撑具体能力。3.5.x分支有一个明显变化：构建系统从旧的configure/Makefile迁移到了CMake，这让依赖检测变得更透明，但也意味着如果你不把依赖库提前装到CMake能发现的位置，配置阶段就会悄悄跳过部分驱动。

这五个依赖各有明确分工：PROJ负责坐标系定义与转换，它内部又依赖sqlite存放proj.db数据库；GEOS提供空间几何运算，GDAL的Geometry操作底层直接调它；curl负责HTTP/HTTPS数据源，比如WMS、WMTS、在线瓦片服务；tiff支撑GeoTIFF及部分压缩编码格式；sqlite则同时服务于PROJ和GDAL内部的矢量数据库驱动。它们不是平行关系，而是有严格的先后约束，编译顺序搞反了，后面CMake配置时就会报库找不到或版本不满足。

还有一个容易忽略的点：GDAL内部对TIFF、PNG、JPEG等格式有内置实现，遇到外部库缺失时会自动走内部实现，配置输出看起来不会失败，但一些高级能力就没了。这种“配置成功但功能缩水”的情况，比直接报错更难发现。所以编译前把依赖树的角色理清楚，是减少后续返工的关键。

2.2 资源包里各源码包的角色与版本匹配

从资源清单看，这套GDAL 3.5.3编译方案对应的依赖包如下：

这里有个容易误判的点：sqlite的amalgamation包与dll-win64包不是二选一，而是配合使用。amalgamation是合并后的C源码，用来自己编译出符合同一版本的DLL；dll-win64包则是官方已经编好的二进制，里面带了运行时DLL和头文件。我一般把两个包都解压到同一依赖目录，编译期用自己编的导入库，部署时再统一归集DLL。

版本对应关系也值得说一句：GDAL 3.5.3推荐的PROJ版本通常是9.x，而PROJ 9.2.1又要求sqlite至少3.11以上，这套组合里sqlite 3.36完全满足要求。GEOS 3.12.1与GDAL 3.5.3的C API兼容性也经过验证，不需要额外打补丁。

2.3 编译环境约定与依赖根目录

在Windows上编这套库，我强烈建议先建立一个统一的依赖根目录，避免每个库散落在不同盘符，后面配置GDAL时长到怀疑人生。目录结构可以这样定：

C:\gdal-deps\src 存放全部源码包解压目录 C:\gdal-deps\install 存放各依赖库的安装产物 C:\gdal-deps\runtime 存放最终归集的所有DLL

源码包按“名称-版本”解压到src下，每个依赖库在install下拥有独立子目录，比如install\proj、install\geos。这样GDAL的CMake配置阶段只需要把所有install子目录通过CMAKE_PREFIX_PATH统一传进去，find_package就能按顺序检索到。

VS2019需要安装“使用C++的桌面开发”工作负载，并打开x64 Native Tools Command Prompt，或者使用Developer PowerShell并切换到x64环境。这里有一个必须反复确认的点：终端标题栏或者命令行提示符必须明确显示x64，否则后续编译出来的库是32位的，最终链接时会出现LNK1112之类的不明错误。

3. 五步编齐前置库：sqlite、geos、PROJ、curl、tiff的顺次与参数

3.1 编译sqlite：用MSVC直接出DLL

sqlite-amalgamation包解压后就是一个sqlite3.c加两个头文件，不需要CMake，直接用VS2019的x64命令行编译出DLL和导入库。先切到源码目录，执行以下命令：

cd C:\gdal-deps\src\sqlite-amalgamation-3360000 # 编译Release目标文件，开启PROJ需要的一些特性宏 cl /O2 /DWIN64 /DNDEBUG /D_USRDLL /DSQLITE_ENABLE_COLUMN_METADATA /DSQLITE_ENABLE_FTS3 /DSQLITE_ENABLE_RTREE /c sqlite3.c # 链接生成DLL与导入库 link /DLL /OUT:sqlite3.dll sqlite3.obj

参数解释：/O2是速度优化宏，/DWIN64告诉编译器按64位处理，/DNDEBUG关闭运行期断言检查。SQLITE_ENABLE_COLUMN_METADATA这个宏对PROJ尤其重要，PROJ在读取proj.db元数据时会依赖列名查询接口，不开启这个宏，后面PROJ的CMake配置阶段可能检测到sqlite但功能识别不完全。SQLITE_ENABLE_FTS3和SQLITE_ENABLE_RTREE分别是全文检索与空间索引能力，GDAL的矢量驱动在某些场景会用到，建议一并打开。

link命令结束后目录下会有sqlite3.dll、sqlite3.lib、sqlite3.exp三个文件。把这两个包里的头文件和库整合到同一个目录：

mkdir C:\gdal-deps\install\sqlite copy sqlite3.h sqlite3.lib sqlite3.dll C:\gdal-deps\install\sqlite\

如果你拿到sqlite源码后不想自己编译，也可以直接解开sqlite-dll-win64-x64包，跳过这一步。但自己编译的好处是宏选项可控，后面排查问题时有底。

3.2 geos：CMake三步安装

geos-3.12.1是纯CMake项目，编译流程最简单，但要注意GDAL的Geometry操作对GEOS的C++接口调用很频繁，编译时保持Debug信息与Release优化并存会比较合理。命令如下：

cd C:\gdal-deps\src\geos-3.12.1 cmake -B build -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON -DCMAKE_INSTALL_PREFIX=C:\gdal-deps\install\geos cmake --build build --config Release --target install --parallel 8

-B build表示在源码目录下创建build子目录存放所有生成文件，避免污染源码。BUILD_SHARED_LIBS取ON时生成geos.dll，这样GDAL运行期不再需要把GEOS静态塞进自己的DLL，各种模块独立更新。INSTALL_PREFIX指到install\geos，之后GDAL会从这个前缀下找geos的头文件和导入库。

如果你的机器装了多个Visual Studio版本，最好在cmake配置命令里显式加上-G “Visual Studio 16 2019” -A x64，让工具链锁定到VS2019的x64平台。不加也能编，但CMake可能挑到最新版本，给后面留隐患。build命令里的--parallel 8是按8线程并发，按CPU线程数调整。

3.3 PROJ 9.2.1：把sqlite正确传进CMake

PROJ是整套依赖里对sqlite绑得最紧的一个，编译时它需要头文件和导入库来链接sqlite3。如果你省略了这两个参数，PROJ配置阶段会显示找不到sqlite，随后自动降级成不支持数据库的版本，GDAL编译时虽然不报错，但坐标转换功能会大面积失效。

cd C:\gdal-deps\src\PROJ-9.2.1 cmake -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=C:\gdal-deps\install\proj -DSQLITE3_INCLUDE_DIR=C:\gdal-deps\install\sqlite -DSQLITE3_LIBRARY=C:\gdal-deps\install\sqlite\sqlite3.lib -DBUILD_SHARED_LIBS=ON -DENABLE_TESTS=OFF cmake --build build --config Release --target install --parallel 8

SQLITE3_INCLUDE_DIR指到包含sqlite3.h的目录，SQLITE3_LIBRARY指到导入库文件。这两个变量名在PROJ 9.x里是固定的，不要写成SQLITE_INCLUDE_DIR，旧版本变量名和9.x不一样，照抄旧教程会配置无效。ENABLE_TESTS设OFF可以跳过测试编译，省下不少时间。

安装完成后，install\proj目录下除了bin和lib，还有一个share\proj子目录，里面放着proj.db。这个数据库文件对PROJ运行是刚需，后面部署阶段必须带上。

3.4 curl：关闭多余协议，降低耦合

curl在GDAL里主要服务于网络驱动，比如读取在线瓦片、WFS查询。Windows下curl的CMake默认会尝试检测一堆外部依赖，比如OpenSSL、libssh2、zlib，这些对GIS场景大多数不是必需项，建议主动关掉：

cd C:\gdal-deps\src\curl-8.2.1 cmake -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=C:\gdal-deps\install\curl -DBUILD_CURL_EXE=OFF -DCURL_USE_OPENSSL=OFF -DCURL_USE_LIBSSH2=OFF -DHTTP_ONLY=ON -DBUILD_SHARED_LIBS=ON cmake --build build --config Release --target install --parallel 8

CURL_USE_OPENSSL关掉后，HTTPS的TLS能力由Windows系统的SChannel提供，对大多数内网和公网瓦片服务已经够用。如果你的业务场景需要访问带自签名证书或特殊CA的HTTPS服务，才需要额外引入OpenSSL并做好证书配置，一般项目不必在编译期增加这个依赖链。

BUILD_CURL_EXE取OFF是因为GDAL只依赖libcurl，不需要生成curl命令行工具。HTTP_ONLY把协议限制在HTTP/HTTPS，代码体积和编译时间都能降下来。

3.5 tiff：默认参数就能过，别折腾旧nmake方案

tiff-4.5.0是五个前置依赖里最省心的，CMake默认参数基本都能直接编过。需要注意的只是把工具和测试关闭，避免生成多余的可执行文件：

cd C:\gdal-deps\src\tiff-4.5.0 cmake -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=C:\gdal-deps\install\tiff -DBUILD_SHARED_LIBS=ON -Dtiff-tools=OFF -Dtiff-tests=OFF cmake --build build --config Release --target install --parallel 8

网上有些旧教程还在用nmake方式编tiff，4.x版本已经不再维护nmake的构建脚本，照那个流程走会卡在生成配置那一步。直接用CMake，干净利落。安装完成后install\tiff\bin下应该有tiff.dll，GDAL配置时通过它识别外部libtiff。

4. 编译GDAL 3.5.3主库：CMake配置、x64-release产出与文件整理

4.1 GDAL 3.5.3的CMake配置参数

五个前置库就位后，GDAL主库的配置阶段非常清晰。核心是把所有依赖的install目录通过CMAKE_PREFIX_PATH一起传给CMake：

cd C:\gdal-deps\src\gdal-3.5.3 cmake -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=C:\gdal-deps\install\gdal-3.5.3 -DCMAKE_PREFIX_PATH="C:\gdal-deps\install\geos;C:\gdal-deps\install\proj;C:\gdal-deps\install\curl;C:\gdal-deps\install\tiff" -DGDAL_USE_GEOS=ON -DGDAL_USE_TIFF=ON -DGDAL_USE_CURL=ON -DGDAL_USE_PROJ=ON -DBUILD_APPS=ON -DBUILD_SHARED_LIBS=ON

CMAKE_PREFIX_PATH多路径时用分号分隔，注意路径里别带空格与中文，Windows下这俩最容易引发诡异报错。GDAL_USE_*是驱动开关，分别对应GEOS、TIFF、CURL和PROJ。这里有个细节：我们传了外部tiff的路径，所以GDAL_USE_TIFF要显式设为ON，才能让CMake优先选外部libtiff而不是内部实现。

配置结束后不要急着编译，先看CMake输出里每个外部库的检测状态。找到带PROJ、GEOS、CURL、TIFF关键字的状态行，确认它们显示的都是找外部库成功，而不是“not found”或“internal”。这一步的疏忽是很多人后面功能缺失的根源。

4.2 编译与安装GDAL

配置正确后，执行编译和安装：

cmake --build build --config Release --target install --parallel 8

编译时长取决于机器配置，通常在十分钟到半小时之间。install完成后，install\gdal-3.5.3\bin下会生成gdal.dll，以及gdalinfo.exe、ogrinfo.exe等命令行工具；lib目录下是gdal_i.lib导入库，include目录下是全部头文件。如果只做开发调试，BUILD_SHARED_LIBS保持ON即可；如果想把GDAL静态编进自己的库，把该选项切OFF，但需要把依赖库也全部统一成静态版本，编译期配置会更加复杂，我一般不推荐这种用法。

4.3 把依赖DLL与GDAL文件整理到发布目录

GDAL运行期不仅需要gdal.dll，还要同时找到proj.dll、geos.dll、curl.dll、tiff.dll和sqlite3.dll。Windows加载DLL是按EXE所在目录、系统PATH、当前工作目录的顺序查找，GDAL不会自动去install目录下找这些依赖。最省心的做法是把所有DLL收进同一个runtime目录：

mkdir C:\gdal-deps\runtime xcopy C:\gdal-deps\install\gdal-3.5.3\bin\*.dll C:\gdal-deps\runtime\ /Y xcopy C:\gdal-deps\install\proj\bin\*.dll C:\gdal-deps\runtime\ /Y xcopy C:\gdal-deps\install\geos\bin\*.dll C:\gdal-deps\runtime\ /Y xcopy C:\gdal-deps\install\curl\bin\*.dll C:\gdal-deps\runtime\ /Y xcopy C:\gdal-deps\install\tiff\bin\*.dll C:\gdal-deps\runtime\ /Y xcopy C:\gdal-deps\install\sqlite\*.dll C:\gdal-deps\runtime\ /Y

PROJ还需要proj.db。把这个数据文件连同share目录一起复制到应用相对路径中：

xcopy C:\gdal-deps\install\proj\share\proj C:\gdal-deps\runtime\share\proj /E /Y

如果你不想复制数据文件，也可以设置环境变量PROJ_DATA指向install\proj\share\proj，PROJ运行时会优先读取该变量。两种方式都能解决proj.db缺失问题，按项目部署习惯选择。

5. 排查GDAL编译与集成的4个高频坑：从路径错位到版本串库

5.1 配置输出正常，但驱动实际没启用

现象：CMake配置GDAL时没有报错，收尾后编译也顺利通过，但运行gdalinfo查看某格式信息时，发现驱动列表比预期少了很多，或者要求输入“-if”参数才能识别格式。

原因：CMake对缺失的依赖库默认只给Warning，不给Error，呈现在配置输出里就是“GDAL_USE_*不是ON就是OFF”的状态。如果CMAKE_PREFIX_PATH拼错路径，或某个依赖安装目录里缺少正确的lib文件，CMake会静默跳过该驱动，而不是中止配置。

解决：配置结束后在build目录里打开CMakeCache.txt，找GDAL_USE_PROJ、GDAL_USE_CURL、GDAL_USE_TIFF、GDAL_USE_GEOS这几个条目，逐一确认值是ON。再检查状态行里是否出现“found”字样。如果发现某个依赖被识别成internal或not found，把build目录整个删掉重新配置，不要只改参数，否则残留缓存会继续影响判断。

5.2 运行时提示找不到proj.dll或geos.dll

现象：GDAL编译成功，把gdal.dll放进自己的程序目录后启动，系统弹窗提示“由于找不到PROJ_GIS_xxx.dll，无法继续执行代码”。

原因：程序链接的是导入库，运行期需要对应DLL出现在Windows的DLL搜索路径里。很多人只拷贝了gdal.dll，遗漏了proj.dll、geos.dll、sqlite3.dll等依赖DLL。GDAL在初始化时是运行时动态加载外部库，缺哪个DLL就报哪个，定位起来还得一个一个试。

解决：把第4.3节runtime目录下的所有DLL一次性放进程序EXE所在目录，或者把C:\gdal-deps\runtime加进系统PATH。我倾向显式复制到程序目录，这样不会污染系统的其他进程环境，发布时整目录带走即可。

5.3 坐标转换报错：failed to load proj.db

现象：程序调GDAL坐标系转换函数，返回错误信息类似“PROJ: proj_db_initialize failed to open database”，或者用projinfo命令都查不到坐标系定义。

原因：proj.db文件没有经过安装步骤复制到应用能找到的位置。GDAL本身不直接管理proj.db，它把这个职责留给了PROJ。很多编译教程只讲了怎么出DLL，没提数据文件，导致这一步被漏掉。

解决：把install\proj\share\proj目录完整复制到程序运行目录下的share\proj相对路径，或者设置PROJ_DATA环境变量指向该目录。注意proj.db与proj.dll版本要一致，混用不同版本可能导致初始化失败。我遇到过拿旧版proj.db替换新版的情况，报错信息更加隐晦，最后干脆每次编译都强制把share目录一并复制。

5.4 多版本VS并存与32/64位混编问题

现象：CMake配置过程中提示检测到多个编译器，或者生成的工程文件用VS2017能打开但编译到一半报std::string链接错误；另一种情况是x64应用链接时出现LNK1112模块计算机类型冲突。

原因：机器上安装了多个Visual Studio版本时，不带-G参数的cmake命令会按默认选择编译器，导致生成的构建配置不是VS2019。32/64位混编则多是因为打开了普通Command Prompt，而不是x64 Native Tools Command Prompt，环境变量里的LIB和INCLUDE还指向32位目录。

解决：在所有依赖库和GDAL的配置命令里统一加-G “Visual Studio 16 2019” -A x64，以明确定位工具链。同时，编译全程坚持从x64 Native Tools Command Prompt启动终端，不要中途切换窗口或混用不同终端。这两个习惯养成后，这个类别的问题基本不会再出现。

6. 编译结果验证与库文件再整理：用最快的方法确认可用

6.1 先跑命令行工具做冒烟验证

拿到编译产物后，我第一件事不是写C++程序，而是先跑gdalinfo，用命令行工具把整条运行时链路过一遍。这能同时验证头文件、导入库、DLL和依赖数据文件是否都正常：

C:\gdal-deps\install\gdal-3.5.3\bin\gdalinfo.exe --version C:\gdal-deps\install\gdal-3.5.3\bin\gdalinfo.exe C:\sample\demo.tif

第一条命令输出GDAL 3.5.3的版本号，第二条能读取一张GeoTIFF并打印栅格尺寸、波段数、坐标系统。两条都成功，说明gdal.dll已经能正确加载外部依赖，GeoTIFF驱动也工作在外部libtiff上。接着验证PROJ链路：

C:\gdal-deps\install\proj\bin\projinfo.exe EPSG:4326

如果输出包含完整的坐标系定义名称与转换参数，说明proj.db被正确识别，sqlite链接也没问题。

6.2 在VS2019工程里做最小化引用测试

先建一个空的C++控制台项目，在项目属性里按这张表配置：

然后写一个最小验证程序：

#include "gdal_priv.h" #include <iostream> int main() { GDALAllRegister(); std::cout << "GDAL版本: " << GDALVersionInfo("RELEASE_NAME") << std::endl; return 0; }

编译并运行，如果控制台输出“GDAL版本: 3.5.3”，说明头文件版本、导入库和运行期DLL三者完全匹配。如果报缺失模块，回到第5.2节检查DLL目录；如果输出版本号不对，回头确认是不是链接了旧的gdal_i.lib。

6.3 我这边的维护习惯

这套流程我前后踩过不少坑，尤其是DLL路径和proj.db这两个环节，每次都能在新机器上重新上演一次。从那以后我每在一台新机器上部署GDAL，都会强制走一遍：先整理依赖目录结构，再逐一编译前置库，配置GDAL后必须查看CMakeCache确认驱动状态，最后统一收DLL并做冒烟验证。这套流程看似繁琐，但省下的调试时间远多过编译时间。希望这份笔记能帮你少绕几次弯路，也祝你顺利编译出自己满意的x64-release GDAL库文件。

本文还有配套的精品资源，点击获取