GDAL 3.4 package: Full-featured GIS functionality on RHEL

February 27, 2026
Filip Janus
Related topics:
C, C#, C++Open sourceProgramming languages & frameworks
Related products:
Red Hat Enterprise Linux

When deploying Red Hat Enterprise Linux (RHEL) 9 systems for geospatial workloads, administrators quickly discover that the Geospatial Data Abstraction Library (GDAL) package in AppStream provides only minimal functionality. Attempts to perform common operations, such as converting Shapefile to GeoJSON with ogr2ogr, inspecting GeoTIFF metadata with gdalinfo, or importing spatial data into PostGIS, fail with driver errors. This GDAL package provided by RHEL ships only the bare minimum: Virtual Raster (VRT) and In Memory Raster (MEM) format drivers.

This limitation is intentional. Red Hat Enterprise Linux provides a simplified version of the GDAL package in the AppStream repository to focus on minimizing dependencies, reducing system security exposure, and maintaining long-term stability throughout the RHEL lifecycle. The minimal version is sufficient for teams that only need GDAL as a build dependency for another package. However, production geospatial workloads require support for formats such as GeoTIFF, JPEG, PNG, Shapefile, and GeoJSON. Data conversion pipelines, spatial analysis jobs, and map-tile rendering all depend on format drivers that the base package does not include.

Extra Packages for Enterprise Linux

To address these requirements, the gdal3.4 package is available in Extra Packages for Enterprise Linux (EPEL).

This compatibility package is designed to:

  • Allow parallel installation alongside the RHEL GDAL package.
  • Avoid file conflicts.
  • Maintain compatibility with standard build tools.

This is not a replacement for the system package, but provides an alternative when requiring a broader set of drivers and formats.

The parallel installation approach

Keeping two versions of the same library on a single system is a packaging challenge that every sysadmin will appreciate. The gdal3.4 package solves this through three deliberate design choices that enable parallel installation while maintaining system integrity.

The most visible difference is in the command-line utilities. All GDAL tools are installed with the gdal3.4- prefix—gdal3.4-gdalinfo, gdal3.4-ogr2ogr, gdal3.4-ogrinfo, and so on. This naming convention prevents any file conflicts with the system-provided version. From a sysadmin's perspective, this means you can invoke the full-featured version explicitly while leaving the system default untouched. More importantly, if any other RPM on the system depends on the base GDAL binaries, those dependencies remain satisfied. No file from the base package is overwritten or diverted, which means automated builds and CI pipelines continue to work exactly as before.

The second design choice concerns shared libraries and development headers. These are placed in standard system locations (/usr/include/gdal/ for headers, /usr/lib64/ for libraries), using the same paths as the base package. The linker distinguishes between versions through the library SONAME. The gdal3.4 package provides libgdal.so.30, while RHEL's base package uses libgdal.so.36. Because the gdal3.4-devel package conflicts with gdal-devel (they cannot be installed simultaneously), the pkg-config file at /usr/lib64/pkgconfig/gdal.pc points to the correct library version. This means compiling a custom application against the full GDAL requires no special flags or modified build scripts. When you run pkg-config --libs gdal, it returns the linker flags for libgdal.so.30, and existing Makefiles or CMake projects pick up the compat version transparently. This is especially valuable in environments where dozens of internal tools are rebuilt nightly from a shared spec: zero build-script changes means zero risk of introducing regressions.

The third design element addresses format-driver plug-ins. These are shipped in their own directory (/usr/lib64/gdal3.4-gdalplugins), separate from the base package's plug-in path. This separation prevents ABI mismatches where the other version at runtime accidentally loads a plug-in compiled against one GDAL version, which would cause crashes or data corruption. The separate plug-in directory ensures that each GDAL installation loads only plug-ins compiled against its own ABI.

Practical implications

The following outlines the features and typical use cases of the full-featured GDAL version available in RHEL.

The full-featured GDAL version provides:

  • Support for common raster and vector formats.
  • Data conversion with ogr2ogr.
  • Language bindings (e.g., Python).

Typical use cases include:

  • Importing OpenStreetMap data.
  • Server-based map services.
  • Data transformation pipelines.
  • Applications requiring spatial analysis.

Binary names

The prefixed utilities can affect automation scripts that expect standard binary names like ogr2ogr. Options to address this include:

  • Modifying scripts to use the prefixed binaries.
  • Creating wrapper scripts.
  • Using symlinks in the local environment.

This is a trade-off between parallel installation and compatibility with existing workflows.

Practical usage examples

The most straightforward solution for scripts expecting standard binary names is to create symlinks. Next, we will discuss two approaches.

User-only symlinks

Create symlinks in your home directory for personal use as follows:

# Create a local bin directory
mkdir -p ~/bin
# Create symlinks for common GDAL utilities
ln -s /usr/bin/gdal3.4-gdalinfo ~/bin/gdalinfo
ln -s /usr/bin/gdal3.4-ogr2ogr ~/bin/ogr2ogr
ln -s /usr/bin/gdal3.4-ogrinfo ~/bin/ogrinfo
ln -s /usr/bin/gdal3.4-gdal_translate ~/bin/gdal_translate
ln -s /usr/bin/gdal3.4-gdalwarp ~/bin/gdalwarp
# Add ~/bin to PATH (add this to your ~/.bashrc or ~/.zshrc)
export PATH="$HOME/bin:$PATH"

System-wide symlinks

System-wide access requires root privileges.

# Create symlinks in /usr/local/bin (available to all users)
sudo ln -s /usr/bin/gdal3.4-ogr2ogr /usr/local/bin/ogr2ogr
sudo ln -s /usr/bin/gdal3.4-ogrinfo /usr/local/bin/ogrinfo
sudo ln -s /usr/bin/gdal3.4-gdalinfo /usr/local/bin/gdalinfo
sudo ln -s /usr/bin/gdal3.4-gdal_translate /usr/local/bin/gdal_translate
sudo ln -s /usr/bin/gdal3.4-gdalwarp /usr/local/bin/gdalwarp

Warning: Creating symlinks in system-wide locations (i.e., /usr/local/bin) can lead to the following conflicts:

  • /usr/local/bin typically has precedence over /usr/bin in PATH, so your symlinks will take precedence over RHEL's binaries.
  • However, if you install the RHEL gdal package after creating symlinks, it may overwrite your symlinks with its own binaries (if the package installs files to /usr/local/bin).
  • Package updates of RHEL gdal may also replace your symlinks.
  • User-only symlinks in ~/bin avoid these conflicts since they are outside system package management.

After creating symlinks, existing scripts that call ogr2ogr, gdalinfo, etc. will automatically use the gdal3.4- prefixed versions.

Final thoughts

RHEL provides a minimal GDAL package aligned with enterprise requirements for stability and security. The gdal3.4 package in EPEL allows deployment of full GDAL functionality without replacing the system package or violating packaging standards. For environments requiring broader format support and integration with GIS tools, this package provides a practical solution while maintaining standard system management practices.