Repository navigation
fix(win): build hdf5, netcdf-c and cfitsio from vcpkg instead of the GisInternals SDK - #248
Merged
Merged
Conversation
…GisInternals SDK (#246) The Windows runtime package inherited hdf5.dll (HDF5 1.12.0), netcdf.dll (netCDF-C 4.8.1) and cfitsio.dll (CFITSIO 3.49) from the prebuilt GisInternals SDK (release-1930-x64). All three predate fixes for families of CVEs reported in #246. Linux and macOS already build these from vcpkg and resolve to HDF5 2.2.0, netCDF-C 4.9.3 and CFITSIO 4.7.0. Add cfitsio, hdf5 and netcdf-c to the windows-dynamic feature so vcpkg supplies them, pin HDF5_ROOT / netCDF_ROOT / CFITSIO_ROOT to the vcpkg prefix (searched ahead of CMAKE_PREFIX_PATH, which also contains the SDK), and set GDAL_USE_HDF5=ON, GDAL_USE_NETCDF=ON, GDAL_USE_CFITSIO=ON so a resolution miss fails the configure rather than silently dropping the drivers. Copy-DependentDLLs falls back to the SDK bin directory, so a failed resolution would repackage the old DLLs with CI still green. Assert after collection that the packaged hdf5.dll, hdf5_hl.dll, netcdf.dll and cfitsio.dll are byte-identical to the vcpkg builds. HDF4 (hdf.dll, mfhdf.dll, xdr.dll, szip.dll) intentionally stays from the SDK - it has no vcpkg port. szip DLL clash: the SDK ships szip.dll for HDF4, and vcpkg's default hdf5[szip] feature pulls libaec which also produces szip.dll. To avoid a wrong-ABI collision, hdf5 is installed with default-features off (zlib only); netcdf-c's transitive dependency on hdf5 also specifies default-features: false, so szip is never pulled in and HDF4 keeps the SDK's original szip.dll.
Reverses the szip-off decision: dropping szip means Windows cannot read szip-compressed HDF5/netCDF-4 files that Linux and macOS can (both use hdf5 with default features including szip via libaec). libaec 1.1.7 on MSVC produces aec.dll + szip.dll (OUTPUT_NAME "szip" in src/CMakeLists.txt). The szip.dll is a drop-in replacement exporting the SZ_* API that the SDK HDF4 (hdf.dll, mfhdf.dll) imports - the same arrangement Debian uses for libhdf4 + libaec. Because VCPKG_INSTALLED\bin is searched before SDK_PREFIX\bin in Copy-DependentDLLs, the vcpkg szip.dll supersedes the SDK copy and serves both HDF5 and HDF4 at runtime. Also makes the hl feature explicit on hdf5 in vcpkg.json; hdf5 2.x does not build hl by default and the hdf5_hl.dll assertion relied solely on netcdf-c pulling it in transitively. Adds szip.dll and aec.dll to the byte-identical hash assertions.
CMake's FindHDF5 module, when given HDF5_ROOT, finds the HDF5 2.x config file and reads the version (2.1.1) but does not populate the legacy HDF5_INCLUDE_DIRS variable, causing GDAL's configure to fail with "Could NOT find HDF5 (missing: HDF5_INCLUDE_DIRS)". Drop HDF5_ROOT and rely on CMAKE_PREFIX_PATH ordering (vcpkg is listed before the SDK), matching the linux build which uses the same HDF5 2.x from vcpkg without HDF5_ROOT. GDAL_USE_HDF5=ON still catches a total miss, and the byte-identical DLL assertion catches accidental SDK resolution at package time.
Root cause: without HDF5_ROOT, FindHDF5 mixes SDK and vcpkg - it found SDK headers (version 1.12.0) but vcpkg hdf5.lib (2.x), plus SDK hdf5_cpp.lib because the cpp feature was missing from vcpkg. GDAL requests HDF5 CXX because KEA is detected from the SDK even with GDAL_USE_KEA=OFF (HAVE_KEA stays true). With HDF5_ROOT alone, FindHDF5 finds the 2.x config file but HDF5_INCLUDE_DIRS stays empty: HDF5 2.x's hdf5-config.cmake uses a lowercase "hdf5_" prefix for its variables that FindHDF5 does not map to the expected uppercase "HDF5_INCLUDE_DIR". Fix: set HDF5_ROOT to restrict library search to vcpkg, pre-set HDF5_C_INCLUDE_DIR and HDF5_CXX_INCLUDE_DIR as cache variables to bypass the broken extraction, and add the cpp feature so the CXX component resolves from vcpkg. Add a CMakeCache.txt post-configure check that fails the build if any HDF5/netCDF/CFITSIO cache entry points under the SDK prefix. Add hdf5_cpp.dll to the byte-identical DLL assertions.
gdal.dll links the vcpkg HDF5 C++ library but imports no symbols from it, so Copy-DependentDLLs never collects hdf5_cpp.dll and the mandatory byte-identity check failed on a file that is correctly absent. Check it only when it is packaged.
This was referenced Oct 14, 2026
This was referenced Oct 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
cfitsio,hdf5[cpp,hl]andnetcdf-cto thewindows-dynamicvcpkg feature, bringing Windows to parity with the Linux and macOS builds (HDF5 2.1.1, netCDF-C 4.9.3, CFITSIO 4.6.4 instead of the SDK's HDF5 1.12.0, netCDF-C 4.8.1, CFITSIO 3.49).HDF5_ROOT,netCDF_ROOTandCFITSIO_ROOTto the vcpkg prefix so the SDK copies inCMAKE_PREFIX_PATHare not picked up. Pre-setHDF5_C_INCLUDE_DIRandHDF5_CXX_INCLUDE_DIRas cache variables to work around an HDF5 2.x / FindHDF5 incompatibility (the 2.x config file uses lowercase variable prefixes that FindHDF5 does not map). SetGDAL_USE_HDF5=ON,GDAL_USE_NETCDF=ON,GDAL_USE_CFITSIO=ONso a resolution miss fails configure.cppfeature is required because GDAL requests HDF5 CXX when KEA is detected from the SDK (even withGDAL_USE_KEA=OFF,HAVE_KEAstays true).hdf5.dll,hdf5_hl.dll,hdf5_cpp.dll,netcdf.dll,cfitsio.dll,szip.dllandaec.dllare byte-identical to the vcpkg builds.HDF4
HDF4 (
hdf.dll,mfhdf.dll,xdr.dll) intentionally stays from the GisInternals SDK - it has no vcpkg port.hdf5 is installed with szip enabled (default feature, via libaec 1.1.7). On MSVC, libaec produces
aec.dll+szip.dll; the latter replaces the SDK'sszip.dllin the package becauseVCPKG_INSTALLED\binis searched beforeSDK_PREFIX\bin. This is safe: libaec'sszip.dllis a drop-in implementing theSZ_*API that the SDK HDF4 imports, matching what Debian does with libhdf4 + libaec.Additional DLLs
netcdf-c adds
tinyxml2.dllto the package payload (new transitive dependency).Verification
Closes #246