企业官网建设流程全解析

1. 项目概述与核心价值

最近在折腾一个地理空间数据处理的项目，核心算法用C++写的，但一涉及到读写各种奇奇怪怪的GIS数据格式（比如Shapefile、GeoTIFF、NetCDF），头就大了。自己从头写解析器？那简直是自讨苦吃，一个文件格式的规范文档就够看半个月。这时候，一个老朋友的名字自然就浮现在脑海里——GDAL。这玩意儿可以说是地理信息领域的“瑞士军刀”，几乎支持所有你能想到和想不到的栅格、矢量数据格式。

但问题来了，官网上提供的预编译包多是针对Windows的，在Linux环境下，特别是我们常用的Ubuntu系统上，想用上最新的、功能完整的GDAL库，尤其是还需要C++接口来开发，总得经历一番“编译安装”的修行。网上教程不少，但要么年代久远对应老版本，要么步骤跳跃缺了关键依赖，要么只装个基础库缺少PROJ、GEOS这些关键组件，跑起来各种报错。这次我就把在Ubuntu 22.04 LTS上，从零开始编译安装最新版GDAL（以目前最新的3.9.0为例）并配置好C++开发环境的完整过程，以及踩过的坑、总结的技巧，详细记录下来。目标很明确：构建一个功能齐全、版本可控、适合C++项目深度集成的GDAL开发环境。无论你是GIS专业的学生，还是需要处理空间数据的后端工程师，这篇“保姆级”教程都能带你走通这条路。

2. 环境准备与核心依赖解析

工欲善其事，必先利其器。在动手编译之前，我们必须把“地基”打牢。这个地基就是编译GDAL所需的各种系统库和工具。很多编译失败的问题，根源都在于依赖缺失或版本冲突。

2.1 系统更新与基础构建工具

首先，确保你的Ubuntu系统是最新的，并安装编译所需的基石工具链。打开终端，执行以下命令：

sudo apt update sudo apt upgrade -y sudo apt install -y build-essential cmake cmake-curses-gui pkg-config

这里简单解释一下：

• build-essential： 这是Ubuntu下的一个元数据包，它包含了gcc,g++,make,libc-dev等最核心的编译工具。没有它，啥也编不了。
• cmake和cmake-curses-gui： GDAL项目使用CMake作为构建系统。cmake是核心命令，cmake-curses-gui（即ccmake）提供了一个终端图形界面，方便后续配置编译选项，对于新手查看和修改选项非常友好。
• pkg-config： 一个用于帮助编译器在编译时和链接时查找库文件（.so）和头文件（.h）的工具。后续很多依赖库都需要它来定位。

2.2 核心地理空间依赖库安装

GDAL的强大建立在众多优秀的开源库之上。我们必须先安装这些“左膀右臂”。以下库是构建一个功能完整GDAL的标配：

sudo apt install -y \ libproj-dev proj-data proj-bin \ libgeos-dev \ libsqlite3-dev \ libcurl4-openssl-dev \ libtiff-dev \ libpng-dev \ libjpeg-dev \ libwebp-dev \ libzstd-dev \ libpq-dev \ libxml2-dev \ libexpat-dev \ libxerces-c-dev \ libnetcdf-dev \ libhdf5-dev \ libopenjp2-7-dev \ libspatialite-dev \ libpoppler-dev \ libpoppler-private-dev \ libgif-dev \ liblzma-dev \ libz-dev

这个命令看起来很长，但非常重要。我们来拆解几个关键角色：

• libproj-dev： PROJ库的开发文件。这是坐标转换的绝对核心，没有它，GDAL的空间参考功能就废了。proj-data包含了转换所需的网格数据，proj-bin提供了命令行工具。
• libgeos-dev： GEOS库的开发文件。提供几何图形拓扑运算（如求交、缓冲、合并等）能力，是GDAL矢量数据处理（OGR部分）的几何引擎。
• libsqlite3-dev和libspatialite-dev： SQLite数据库及其空间扩展Spatialite的支持。很多数据格式（如GPKG）和GDAL自己的虚拟文件系统（/vsizip,/vsicurl）都依赖它。
• libcurl4-openssl-dev： 支持GDAL通过网络（HTTP/HTTPS/FTP）直接读取远程数据，这是现代GIS工作流中非常方便的特性。
• libtiff-dev,libpng-dev,libjpeg-dev： 这些是处理TIFF、PNG、JPEG等常见栅格图像格式所必需的。
• libnetcdf-dev,libhdf5-dev： 用于支持NetCDF和HDF5科学数据格式，这在气象、海洋等领域很常见。
• libpoppler-dev： 提供PDF文件读取支持。如果你想从PDF中提取地理参考地图，这个库是关键。

注意： 使用apt安装的这些库，通常是Ubuntu官方仓库维护的版本，可能不是最新的。但对于作为GDAL的依赖来说，稳定性优先，这些版本已经过充分测试，兼容性有保障。我们的目标是让GDAL本身用上新特性，而不是追求每一个底层依赖都是最新版。

3. 源码获取与编译配置详解

依赖搞定，现在可以请出主角了。我们不推荐用apt install libgdal-dev，因为仓库里的版本往往滞后，且编译选项固定，无法自定义。

3.1 下载最新版GDAL源码

建议直接从GDAL的官方GitHub仓库下载稳定版发布包，这样比直接克隆开发分支（master）更稳定。

# 进入一个常用的工作目录，例如 ~/src cd ~ mkdir -p src cd src # 假设当前最新稳定版是 3.9.0 # 你可以从 https://github.com/OSGeo/gdal/releases 查看最新版本号 wget https://github.com/OSGeo/gdal/releases/download/v3.9.0/gdal-3.9.0.tar.gz # 解压源码 tar -xzvf gdal-3.9.0.tar.gz cd gdal-3.9.0

使用发布包（tar.gz）的好处是代码状态固定，没有正在开发中的不稳定代码，适合生产环境。下载速度慢的话，可以考虑使用镜像源或者先下载到本地再上传。

3.2 使用CMake进行精细化配置

传统的./configure方式正在被淘汰，GDAL官方推荐使用CMake。它更现代，跨平台性更好，配置也更清晰。

首先，我们创建一个独立的构建目录，与源码目录分离，这是一种良好的“影子构建”（out-of-source build）实践，保持源码目录的纯净。

mkdir build cd build

接下来是关键步骤：运行cmake进行配置。这里我提供一个兼顾功能完整性和编译成功率的基础配置命令：

cmake .. \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=/usr/local \ -DBUILD_SHARED_LIBS=ON \ -DGDAL_USE_EXTERNAL_LIBS=ON \ -DGDAL_USE_INTERNAL_LIBS=OFF \ -DGDAL_USE_GEOTIFF_INTERNAL=OFF \ -DGDAL_USE_JPEG_INTERNAL=OFF \ -DGDAL_USE_PNG_INTERNAL=OFF \ -DGDAL_USE_ZLIB_INTERNAL=OFF \ -DGDAL_USE_SQLITE3=ON \ -DGDAL_USE_PROJ=ON \ -DGDAL_USE_GEOS=ON \ -DGDAL_USE_CURL=ON \ -DGDAL_USE_HDF5=ON \ -DGDAL_USE_NETCDF=ON

参数逐条解析：

• -DCMAKE_BUILD_TYPE=Release： 指定编译为发布版本。它会开启编译器优化（如-O3），去掉调试信息，生成性能最优的二进制文件。如果是调试，则改为Debug。
• -DCMAKE_INSTALL_PREFIX=/usr/local： 指定安装路径。/usr/local是Linux系统存放本地安装软件的标准位置。你也可以安装到/opt/gdal或$HOME/local等自定义路径，但需要自己管理环境变量。
• -DBUILD_SHARED_LIBS=ON： 编译生成动态链接库（.so文件）。通常我们都选择动态库，这样多个程序可以共享，节省磁盘和内存。如果希望静态链接，则设为OFF。
• -DGDAL_USE_EXTERNAL_LIBS=ON和-DGDAL_USE_INTERNAL_LIBS=OFF：这是最重要的选项之一。它告诉CMake优先使用我们刚刚通过apt安装的系统库（外部库），而不是使用GDAL源码包里自带的（内部库）。使用系统库更稳定，也能享受系统级的更新和安全补丁。
• -DGDAL_USE_GEOTIFF_INTERNAL=OFF等： 针对具体库（如libgeotiff, libjpeg, libpng, zlib）强制指定使用外部库。确保与我们上一步的安装一致。
• -DGDAL_USE_PROJ=ON等： 显式开启对PROJ、GEOS、CURL、HDF5、NetCDF等关键库的支持。即使系统安装了，这里也要明确打开，否则对应功能不会被编译进去。

执行完cmake命令后，终端会输出大量的检查信息。请仔细浏览最后部分，确保没有红色的“NOT FOUND”错误，并且你需要的驱动（如GTiff, PNG, JPEG, netCDF, HDF5等）显示为“YES”。

如果对默认配置不满意，或者想探索更多选项，可以使用交互式工具ccmake：

ccmake ..

在ccmake界面中，用方向键导航，按Enter键修改布尔型或字符串型选项的值。按c键配置，按g键生成并退出。这是一个调整高级参数（如是否编译Java/Python绑定、特定驱动选项）的好方法。

4. 编译、安装与系统集成

配置无误后，就可以开始编译了。这个过程会比较耗时，取决于你的CPU核心数。

4.1 并行编译与安装

使用make命令并指定-j参数可以充分利用多核CPU，显著加快编译速度。nproc命令可以获取你CPU的逻辑核心数。

# 使用所有可用的CPU核心进行编译 make -j$(nproc)

编译过程可能会持续几分钟到十几分钟。如果遇到错误，通常是某个依赖找不到或者版本不兼容。请根据错误信息回溯，检查对应的-DGDAL_USE_XXX选项是否已正确开启，以及系统库是否已安装-dev版本。

编译成功后，进行安装：

sudo make install

这会将编译好的库文件（libgdal.so）、头文件（.h）、命令行工具（如gdalinfo,ogr2ogr）以及帮助文档安装到/usr/local目录下。

4.2 动态链接库路径配置

安装到/usr/local后，系统可能无法立即找到这个新安装的库。因为默认的库搜索路径（由/etc/ld.so.conf定义）通常包含/usr/lib和/usr/lib/x86_64-linux-gnu，但不一定包含/usr/local/lib。

我们需要更新系统的动态链接器缓存：

sudo ldconfig

这个命令会扫描/etc/ld.so.conf中配置的目录以及像/usr/local/lib这样的标准目录，并更新缓存，使系统能快速定位到libgdal.so。

4.3 验证安装结果

安装完成后，通过几个命令来验证GDAL是否已正确安装且功能完整。

验证命令行工具和版本：

gdalinfo --version gdalinfo --formats | head -20 # 查看支持的栅格格式 ogrinfo --formats | head -20 # 查看支持的矢量格式

如果命令未找到，可能是因为/usr/local/bin不在你的PATH环境变量中。可以临时添加export PATH=/usr/local/bin:$PATH，或者将这句添加到你的~/.bashrc文件中永久生效。

验证核心驱动和依赖：

# 查看GDAL构建时配置的详细信息，检查关键驱动是否启用 gdalinfo --build

在输出信息中，重点关注：

• GEOS support: yes
• PROJ >= 6: yes(版本号)
• Enabled drivers: GTiff, PNG, JPEG, netCDF, HDF5, GPKG, SQLite等等。

一个简单的功能测试：

# 创建一个简单的测试GeoTIFF文件（需要安装GDAL的Python绑定，或者用其他方法） # 这里用gdal_translate做一个格式转换测试（假设你有一个PNG图片） # echo -e "测试数据" > test.txt # 更实际的测试是找一个已有的小TIFF文件，用gdalinfo查看其信息。

5. C++开发环境配置与项目集成

GDAL库安装好了，接下来是如何在C++项目中使用它。这里以手动编译链接和CMake项目集成两种最常见的方式来说明。

5.1 手动编译链接示例

假设我们有一个最简单的C++程序test_gdal.cpp，用于打开一个栅格文件并读取其基本信息。

// test_gdal.cpp #include <iostream> #include "gdal.h" #include "gdal_priv.h" #include "cpl_conv.h" // for CPLMalloc int main() { // 注册所有驱动 GDALAllRegister(); const char* pszFilename = "your_raster_file.tif"; // 请替换为实际文件路径 GDALDataset *poDataset; // 以只读方式打开数据集 poDataset = (GDALDataset *) GDALOpen(pszFilename, GA_ReadOnly); if( poDataset == nullptr ) { std::cerr << "无法打开文件: " << pszFilename << std::endl; return 1; } // 获取图像尺寸和波段数 int nWidth = poDataset->GetRasterXSize(); int nHeight = poDataset->GetRasterYSize(); int nBands = poDataset->GetRasterCount(); std::cout << "文件: " << pszFilename << std::endl; std::cout << "尺寸: " << nWidth << " x " << nHeight << std::endl; std::cout << "波段数: " << nBands << std::endl; // 获取地理变换参数（如果是地理参考图像） double adfGeoTransform[6]; if( poDataset->GetGeoTransform(adfGeoTransform) == CE_None ) { std::cout << "左上角X: " << adfGeoTransform[0] << std::endl; std::cout << "像元宽度: " << adfGeoTransform[1] << std::endl; std::cout << "旋转参数1: " << adfGeoTransform[2] << std::endl; std::cout << "左上角Y: " << adfGeoTransform[3] << std::endl; std::cout << "旋转参数2: " << adfGeoTransform[4] << std::endl; std::cout << "像元高度: " << adfGeoTransform[5] << std::endl; } // 获取投影信息 const char* pszProjection = poDataset->GetProjectionRef(); if( pszProjection != nullptr && strlen(pszProjection) > 0 ) { std::cout << "投影: " << pszProjection << std::endl; } // 关闭数据集 GDALClose((GDALDatasetH) poDataset); return 0; }

使用g++手动编译这个程序：

g++ -o test_gdal test_gdal.cpp \ -I/usr/local/include \ -L/usr/local/lib \ -lgdal \ -std=c++11

参数解释：

• -I/usr/local/include： 告诉编译器在/usr/local/include目录下寻找头文件（gdal.h等）。
• -L/usr/local/lib： 告诉链接器在/usr/local/lib目录下寻找库文件。
• -lgdal： 链接名为libgdal.so的库。
• -std=c++11： 指定C++语言标准，GDAL的C++接口需要C++11或更高版本。

编译成功后，运行前需要确保动态链接器能找到库：

# 临时添加库路径到LD_LIBRARY_PATH export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH ./test_gdal

5.2 CMake项目集成（推荐）

对于正式项目，使用CMake管理构建是更专业和便捷的方式。在你的项目CMakeLists.txt中，可以这样配置：

cmake_minimum_required(VERSION 3.10) project(MyGdalProject) set(CMAKE_CXX_STANDARD 11) # 寻找GDAL包 find_package(GDAL REQUIRED) # 打印找到的GDAL信息，用于确认 message(STATUS "GDAL include dir: ${GDAL_INCLUDE_DIRS}") message(STATUS "GDAL libraries: ${GDAL_LIBRARIES}") add_executable(my_gdal_app main.cpp) target_include_directories(my_gdal_app PRIVATE ${GDAL_INCLUDE_DIRS}) target_link_libraries(my_gdal_app PRIVATE ${GDAL_LIBRARIES})

然后，在编译时，CMake需要知道去哪里找GDALConfig.cmake这个配置文件。因为我们安装到了/usr/local，可能需要通过-D参数指定其路径，或者将/usr/local添加到CMAKE_PREFIX_PATH。

mkdir build && cd build cmake .. -DCMAKE_PREFIX_PATH=/usr/local make ./my_gdal_app

如果find_package(GDAL)失败，最常见的原因是GDAL的CMake配置文件没有安装到标准路径，或者CMAKE_PREFIX_PATH没有设置。可以尝试使用find_library和find_path手动指定。

5.3 集成到VSCode开发环境

如果你使用Visual Studio Code进行开发，确保其C++扩展能正确识别GDAL。关键在于配置c_cpp_properties.json文件（在项目.vscode文件夹下）。

{ "configurations": [ { "name": "Linux", "includePath": [ "${workspaceFolder}/**", "/usr/local/include" // 添加GDAL头文件路径 ], "defines": [], "compilerPath": "/usr/bin/g++", "cStandard": "c17", "cppStandard": "c++17", "intelliSenseMode": "linux-gcc-x64", "configurationProvider": "ms-vscode.cmake-tools" } ], "version": 4 }

对于CMake项目，使用CMake Tools扩展，并在CMakeLists.txt中正确配置find_package(GDAL)即可，VSCode会自动配置IntelliSense。

6. 进阶配置、问题排查与性能调优

环境搭起来只是第一步，在实际开发和部署中，还会遇到各种问题。这里分享一些进阶经验和常见坑的解决方案。

6.1 多版本GDAL共存与管理

有时系统可能需要不同版本的GDAL。例如，某个旧项目依赖GDAL 2.4，而新项目需要GDAL 3.9。不建议强行替换系统版本，而是采用并行安装。

方法：自定义安装路径。在编译时，将CMAKE_INSTALL_PREFIX设置为一个独立目录，例如/opt/gdal-3.9.0。

cmake .. -DCMAKE_INSTALL_PREFIX=/opt/gdal-3.9.0 make -j$(nproc) sudo make install

使用时，通过环境变量LD_LIBRARY_PATH和PATH来切换版本。

export PATH=/opt/gdal-3.9.0/bin:$PATH export LD_LIBRARY_PATH=/opt/gdal-3.9.0/lib:$LD_LIBRARY_PATH # 或者使用模块环境管理工具（如 environment modules 或 Lmod）

更优雅的方案是使用update-alternatives工具（Debian/Ubuntu系列）：

# 假设已安装到 /opt/gdal-3.9.0 sudo update-alternatives --install /usr/bin/gdalinfo gdalinfo /opt/gdal-3.9.0/bin/gdalinfo 100 sudo update-alternatives --install /usr/bin/ogr2ogr ogr2ogr /opt/gdal-3.9.0/bin/ogr2ogr 100 sudo update-alternatives --install /usr/lib/x86_64-linux-gnu/libgdal.so libgdal.so /opt/gdal-3.9.0/lib/libgdal.so 100 # 然后使用 sudo update-alternatives --config gdalinfo 等进行切换

6.2 编译与运行常见问题排查

问题1：cmake配置时，找不到PROJ、GEOS等库。

• 症状： 输出中显示PROJ: NOT FOUND。
• 原因： 虽然用apt安装了libproj-dev，但CMake可能因为pkg-config文件路径问题或版本要求不满足而找不到。
• 解决：
  1. 确认开发包已安装：dpkg -l | grep libproj-dev。
  2. 尝试安装更新的版本，或从源码编译PROJ/GEOS。
  3. 在cmake命令中手动指定路径：-DPROJ_INCLUDE_DIR=/usr/include -DPROJ_LIBRARY=/usr/lib/x86_64-linux-gnu/libproj.so。使用ccmake查看具体的变量名。

问题2：编译过程中报错，提示undefined reference to ...。

• 症状： 链接阶段失败，找不到某个符号（函数）。
• 原因： 通常是链接库的顺序不对或缺少某个依赖库。GDAL依赖很多库，链接时需要将它们都包含进来。
• 解决：
  1. 手动编译时，确保链接了所有必要的库。一个相对完整的链接命令可能像这样：

  g++ ... -lgdal -lgeos_c -lproj -ltiff -lpng -ljpeg -lcurl -lsqlite3 -lz -lpthread -ldl

  2. 使用pkg-config自动获取链接参数（如果GDAL安装了pkg-config文件）：

  g++ ... $(pkg-config --cflags --libs gdal)

  3. 在CMake项目中，find_package(GDAL)通常能自动处理好传递性依赖。

问题3：程序运行时崩溃，报错GLIBCXX_3.4.29‘ not found或类似。

• 症状： 在编译环境运行正常，但在另一个较老系统上运行出错。
• 原因： 编译使用的GCC版本较高，生成的二进制文件依赖新版本的C++标准库，而目标系统GLIBC版本太老。
• 解决： 这是Linux C++程序分发的经典问题。有几种思路：
  1. 在目标系统上编译： 这是最根本的解决办法。
  2. 使用静态链接： 编译GDAL和你的程序时都使用静态链接（-static-libstdc++，注意这通常只链接libstdc++，其他库如libgcc可能仍需动态链接）。但GDAL本身依赖众多，全静态链接很复杂。
  3. 降低编译环境GCC版本： 在较老的Ubuntu LTS版本（如18.04）上构建，以兼容更多系统。
  4. 使用Docker分发： 将你的应用和整个运行环境（包括特定版本的GDAL和libstdc++）打包到Docker镜像中。

问题4：读取某些特定格式文件（如ECW、MrSID）失败。

• 原因： 这些是专利格式，GDAL默认不包含其驱动。或者对应的依赖库（如libecwj2）没有安装。
• 解决：
  1. 对于开源或可获取的驱动，需要单独下载源码编译并集成。例如，要添加ECW支持，需要先获取ECW SDK，然后在配置GDAL时通过-DECW_ROOT等参数指定其路径。
  2. 对于专利格式，请确保你拥有合法的SDK许可证。
  3. 使用gdalinfo --formats查看已安装的驱动列表，确认所需驱动是否在列。

6.3 性能调优与编译选项

对于高性能应用，可以在编译GDAL时开启一些优化选项。

• 链接时优化（LTO）： 在cmake配置时添加-DCMAKE_INTERPROCEDURAL_OPTIMIZATION=ON。这可以在链接阶段进行跨模块优化，可能提升运行时性能，但会显著增加编译时间和内存消耗。
• 针对特定CPU架构优化： 使用-march=native让编译器生成针对你当前CPU型号最优化的代码。可以在CMakeLists.txt中设置：

  set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -march=native")

• 启用SIMD指令集： 确保编译器标志中包含了-msse4.2、-mavx2等（取决于你的CPU）。-march=native通常会自动包含这些。
• 并行计算支持： 如果处理算法支持并行（如重采样、瓦片计算），确保你的程序使用了GDAL的多线程API（如GDALDataset::GetRasterBand的IRasterIO操作），并且编译时开启了OpenMP支持（通常GCC默认开启）。

6.4 空间数据库与网络数据源支持增强

如果你需要更强大的空间数据库支持（如PostGIS, Oracle Spatial）或更稳定的网络访问，可能需要额外编译相关驱动。

• PostgreSQL/PostGIS： 确保安装了libpq-dev（我们之前已经装了）。GDAL会自动编译出PostgreSQL驱动。运行时可能还需要libpq库。
• Oracle： 需要安装Oracle Instant Client的SDK，并在CMake配置中指定-DOCI_INCLUDE_DIR和-DOCI_LIBRARY。
• MySQL： 需要libmysqlclient-dev，并通过-DMYSQL_INCLUDE_DIR等参数配置。
• 网络数据源优化： GDAL的/vsicurl/虚拟文件系统非常有用。可以通过环境变量GDAL_HTTP_MAX_RETRY、GDAL_HTTP_RETRY_DELAY等调整其重试行为。对于大量小文件访问，考虑启用GDAL_DISABLE_READDIR_ON_OPEN或使用CPL_VSIL_CURL_ALLOWED_EXTENSIONS环境变量来限制尝试远程访问的文件扩展名，以提升性能。

7. 维护、升级与清理

系统环境不是一成不变的，GDAL也在持续更新。了解如何维护这个手动编译的环境很重要。

升级GDAL：

1. 前往GDAL发布页面，下载新版本的源码包。
2. 解压到新目录，例如gdal-3.10.0。
3. 重复上述配置、编译、安装步骤。安装路径（CMAKE_INSTALL_PREFIX）可以保持不变（如/usr/local），这样会直接覆盖旧版本。
4. 重要： 安装后务必再次运行sudo ldconfig更新库缓存。
5. 重新编译你的C++项目（如果GDAL的API有变动，可能需要修改代码）。

降级或回滚：如果新版本导致兼容性问题，你需要回退到旧版本。如果你保留了旧版本的源码和构建目录（build），可以重新进入该目录，执行sudo make install进行覆盖安装。如果没有保留，就需要重新下载旧版本源码完整编译安装。这凸显了将GDAL安装到独立目录（如/opt/gdal-3.9.0）并利用update-alternatives管理版本的优势。

清理安装：如果你将GDAL安装到了/usr/local并想彻底移除，可以回到当初的构建目录（build），执行：

sudo make uninstall

如果make uninstall目标不存在（有时CMake工程不提供），则需要手动删除相关文件。主要检查以下目录：

• /usr/local/bin/(删除gdal*,ogr*等可执行文件)
• /usr/local/lib/(删除libgdal.*,libgdal.so等库文件和链接)
• /usr/local/include/(删除gdal目录)
• /usr/local/share/gdal/(删除数据文件、文档等)

手动删除务必小心，避免误删其他软件的文件。这也是为什么有些人更喜欢将软件安装到/opt或$HOME/local下，删除时直接删除整个目录即可，更安全。

整个流程走下来，从依赖安装、源码编译、环境配置到问题排查，基本上覆盖了在Linux（Ubuntu）上为C++项目搭建一个健壮、最新版GDAL开发环境的所有关键环节。核心思路就是：利用系统包管理器解决大部分依赖，从源码编译以获得最新特性和完全控制，通过CMake进行现代化配置，最后妥善集成到你的C++构建系统中。记住，编译大型开源库是Linux开发者的必备技能，过程中遇到的每一个错误和解决过程，都是对系统理解加深的一步。