GDAL 3.13.0 build failure with both netCDF and HDF4 enabled due to HDF4 legacy netcdf.h being picked before netCDF-C header

[pavelToman]

What is the bug?

When building GDAL 3.13.0 with both netCDF and HDF4 support enabled, the build of the GDAL netCDF driver can fail because HDF4’s legacy netCDF compatibility header is picked up before the real netCDF-C header.

In my build environment, frmts/netcdf/netcdfdataset.cpp ends up including:

.../HDF/4.3.1-GCCcore-15.2.0/include/hdf/netcdf.h

before the real netCDF-C API header. Later, netcdf_mem.h from netCDF-C is included, but the expected netCDF-C definitions are missing. This leads to errors such as:

error: ‘EXTERNL’ does not name a type
error: ‘nc_strerror’ was not declared in this scope
error: ‘NC_UINT64’ was not declared in this scope
error: ‘nc_inq_varid’ was not declared in this scope
error: ‘nc_inq_varndims’ was not declared in this scope

The build succeeds when adding:

-DCMAKE_NO_SYSTEM_FROM_IMPORTED=ON

This suggests that the issue is related to CMake include ordering/system include handling when both netCDF and HDF4 are enabled.

Steps to reproduce the issue

1. Build GDAL 3.13.0 with both netCDF and HDF4 support enabled in an environment where dependency include directories are exposed through environment variables such as CPATH/CPPFLAGS.

2. Make sure HDF4 include paths are visible in the compiler environment before or alongside netCDF, for example:

CPATH=.../HDF/4.3.1/include/hdf:.../HDF/4.3.1/include:.../netCDF/4.10.0/include:...

3. Run CMake and build GDAL normally:

cmake <options above> /path/to/gdal-3.13.0
make -j8

The whole cmake command is:

cmake  
-DCMAKE_INSTALL_PREFIX=~/GDAL/3.13.0-foss-2026.1 
-DCMAKE_MESSAGE_LOG_LEVEL=STATUS
-DCMAKE_BUILD_TYPE=Release 
-DCMAKE_INSTALL_LIBDIR:PATH=lib 
-DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF
-DPYTHON_EXECUTABLE=~/software/Python/3.14.2-GCCcore-15.2.0/bin/python
-DPython_EXECUTABLE=~/software/Python/3.14.2-GCCcore-15.2.0/bin/python
-DPython3_EXECUTABLE=~/software/Python/3.14.2-GCCcore-15.2.0/bin/python 
-DGDAL_USE_INTERNAL_LIBS=OFF 
-DGDAL_USE_MYSQL=OFF
-DGDAL_USE_POPPLER=OFF 
-DGEOTIFF_INCLUDE_DIR=$EBROOTLIBGEOTIFF/include 
-DPython_ROOT=$EBROOTPYTHON 
/tmp/easybuild/build/GDAL/3.13.0/foss-2026.1/gdal-3.13.0

4. The build fails while compiling the netCDF driver, for example:

frmts/netcdf/netcdfdataset.cpp

5. Running the failing compile command with -E -H -dD shows that HDF4’s legacy compatibility header is included before the real netCDF-C header:

.../HDF/4.3.1/include/hdf/netcdf.h
.../HDF/4.3.1/include/hdf/hdf2netcdf.h
.../HDF/4.3.1/include/hdf/hdf.h
...
.../netCDF/4.10.0/include/netcdf_mem.h

6. Reconfiguring with the same options plus:

-DCMAKE_NO_SYSTEM_FROM_IMPORTED=ON

allows the build to complete successfully.

Versions and provenance

GDAL was built from the official source tarball:

GDAL 3.13.0
Source: https://download.osgeo.org/gdal/3.13.0/gdal-3.13.0.tar.xz
SHA256: 1c537dd2f4d66f05534ae419bc2af495c2204ce13bb266c8cbd867dd6705f0c7

Build environment:

OS: RHEL 9
System/architecture: cascadelake-ampere-ib
Build framework: EasyBuild
Toolchain: foss 2026.1
Compiler: GCC 15.2.0
MPI: OpenMPI 5.0.10
CMake: 4.2.1
Python: 3.14.2

Relevant dependencies:

netCDF-C: 4.10.0
HDF4: 4.3.1
HDF5: 2.1.1
PROJ: 9.8.1
GEOS: 3.14.1
libgeotiff: 1.7.4
LibTIFF: 4.7.1
SQLite: 3.51.1
cURL: 8.17.0
libxml2: 2.15.1
zlib: 2.3.2

The build uses external dependencies via CMake with:

-DGDAL_USE_INTERNAL_LIBS=OFF
-DGDAL_USE_NETCDF=ON
-DGDAL_USE_HDF4=ON

The issue was observed in an EasyBuild environment where dependency include paths are exported through variables such as CPATH and CPPFLAGS.

Additional context

This may be specific to build environments where external dependency include directories are globally visible through variables such as CPATH or CPPFLAGS, as is common in EasyBuild-based HPC software stacks.

The important point seems to be that the real netCDF-C include directory was present in the GDAL compile command, but it was passed as a system include, while HDF4’s legacy compatibility header remained reachable through the global include environment.

Adding:

-DCMAKE_NO_SYSTEM_FROM_IMPORTED=ON

fixed the build without disabling either netCDF or HDF4 support.

My question is whether GDAL should handle this case more robustly in its CMake configuration, or whether this workaround should be documented for builds that enable both netCDF and HDF4.

This issue was made with help of ChatGPT5.5

[rouault]

1. Build GDAL 3.13.0 with both netCDF and HDF4 support enabled in an environment where dependency include directories are exposed through environment variables such as CPATH/CPPFLAGS.

That's the root cause. I'm surprised this CMAKE_NO_SYSTEM_FROM_IMPORTED=ON cmake setting even fixed the issue for you. I'm a bit skeptical about whether we can properly document that in our doc without confusing users. For me that's a system integration issue, not a GDAL one.
And the one to blame here is HDF4 that should not export netCDF headers to start with.

[pavelToman]

The other fix that works for me was to modify CPATH and CPPFLAGS envs before cmake both make step as:

    'export CPATH="$(echo "$CPATH" | tr ":" "\\n" | '
    'grep -v "^$EBROOTHDF/include/hdf$" | '
    'grep -v "^$EBROOTHDF/include$" | paste -sd: -)" && '
    'export CPPFLAGS="$(printf "%s\\n" $CPPFLAGS | '
    'grep -v "^-I$EBROOTHDF/include/hdf$" | '
    'grep -v "^-I$EBROOTHDF/include$" | paste -sd" " -)" && '