Update hdf5 2.1.0 with 17commits from develop since 2/5/2026 (#6229)

* Fix MPI Fortran configuration for HDF5Examples (#6206)

When building Fortran parallel examples without MPI wrappers, the
compiler couldn't find mpi.mod because MPI_Fortran_INCLUDE_DIRS
was not populated. This occurred because find_package(MPI) was only
called for C, not Fortran.

Added enable_language(Fortran) and find_package(MPI REQUIRED
COMPONENTS Fortran) to properly configure MPI for Fortran examples,
ensuring MPI include directories and libraries are correctly set.

* Adds RFCs to the RFC table (#6190)

* Added two RFCs to the RFC table

"Adding support for digitally signed plugins to HDF5"
" Write-Ahead log"

* Updated to use the ACM link

* Add HDF5 2.0.0 Library Migration Guide (#6183)

* Add HDF5 2.0.0 Library Migration Guide

* Revise HDF5 migration guide for version 2.0.0

Use 2.0.0 consistently.

* Clarify API changes in HDF5 2.0.0 Migration Guide

* Fixes the "multiple @param documentation sections" doxygen warnings (#6195)

Addresses the "multiple @ param documentation sections" warnings are caused by the interaction of three things:

1. MACRO_EXPANSION = YES with EXPAND_ONLY_PREDEF = NO in Doxyfile.in

2. Versioned API macros in H5version.h like:

\def documentation in APIVersions.dox like:

3. \def H5Tarray_create \api_vers_2{H5Tarray_create,H5Tarray_create1,H5Tarray_create2}

Because Doxygen expands all macros, it sees H5Tarray_create as an alias for H5Tarray_create1. It then associates documentation from both the \def block (for the macro) and the function's own doc block (with \param entries) with the same function — resulting in "multiple @ param documentation sections."

* Update Doxygen version from 1.16.0 to 1.16.1

Use Doxygen 1.16.1 for all platforms. This version includes the latest
bug fixes and improvements while maintaining compatibility with our
documentation format.

* Fix Windows Doxygen installation for version 1.16.1

Handle different Windows binary naming conventions across Doxygen versions:
- 1.16.1 uses: doxygen-VERSION.windows.x64.bin.zip
- 1.16.0 uses: doxygen-VERSION.x64.bin.zip

Try the newer naming convention first, then fall back to the older one
if the download fails. This ensures compatibility across versions.

* Use ssciwr/doxygen-install in setup-doxygen action

Replace direct installation of official Doxygen binaries with
ssciwr/doxygen-install action. This avoids Java documentation parsing
errors that occur with official binaries but not with distribution
builds.

The setup-doxygen action now serves as a thin wrapper around
ssciwr/doxygen-install@f13be16c83 (v1),
using commit hash for security and reproducibility.

* Remove redundant version specification from workflows

The setup-doxygen action already has a default version (1.16.1),
so explicit version specification in workflows is unnecessary.
This follows DRY principles and makes version updates simpler.

* Updates to #6205 (#6208)

* Fix MPI Fortran configuration for HDF5Examples (#6205)

When building Fortran parallel examples standalone without MPI
wrappers, the compiler cannot find mpi.mod because
MPI_Fortran_INCLUDE_DIRS is not populated.

* Use MPI::MPI_Fortran imported target instead of raw MPI variables

Replace manual MPI_Fortran_LIBRARIES, MPI_Fortran_LINK_FLAGS, and
MPI_Fortran_INCLUDE_DIRS usage with the MPI::MPI_Fortran imported
target, which transitively carries all include dirs, compile flags,
and link flags. This eliminates the CMAKE_Fortran_EXE_LINKER_FLAGS
hack and the manual target_include_directories in H5PAR.

* Update nvhpc version to 26.1 with CUDA version 13.1. (#6213)

# branches: [develop]

* Inherit Debug C build flags in Developer build mode (#6182)

* Bump the github-actions group across 1 directory with 11 updates (#6215)

* Bump the github-actions group across 1 directory with 11 updates

Bumps the github-actions group with 11 updates in the / directory:

| Package | From | To |
| --- | --- | --- |
| [actions/cache](https://github.com/actions/cache) | `5.0.1` | `5.0.3` |
| [lukka/get-cmake](https://github.com/lukka/get-cmake) | `4.2.1` | `4.2.3` |
| [softwareforgood/check-artifact-v4-existence](https://github.com/softwareforgood/check-artifact-v4-existence) | `0.3.0` | `0.4.1` |
| [github/codeql-action](https://github.com/github/codeql-action) | `3.31.9` | `4.32.2` |
| [azure/trusted-signing-action](https://github.com/azure/trusted-signing-action) | `0.5.11` | `1.1.0` |
| [cygwin/cygwin-install-action](https://github.com/cygwin/cygwin-install-action) | `7d2dc1e241644c3318bed9ec74115d1929baa681` | `2566376092c4e280f21131be027af3f5bb2420a4` |
| [aws-actions/configure-aws-credentials](https://github.com/aws-actions/configure-aws-credentials) | `5.1.1` | `6.0.0` |
| [vmactions/freebsd-vm](https://github.com/vmactions/freebsd-vm) | `1.3.4` | `1.4.2` |
| [vmactions/openbsd-vm](https://github.com/vmactions/openbsd-vm) | `1.3.1` | `1.3.5` |
| [mpi4py/setup-mpi](https://github.com/mpi4py/setup-mpi) | `1.4.1` | `1.4.2` |
| [actions/setup-python](https://github.com/actions/setup-python) | `6.1.0` | `6.2.0` |

 vmactions/openbsd-vm@d6c29ce1b4 (`1.3.5`) failed to run ssh on the github runner.  271a1ba62300483cfc58345ff9f425f1349a2cab for v1.3.4 was used instead.

* Fix issue with some Subfiling VFD test files not getting deleted (#6212)

* CMake: Fix Fortran cross-compilation support

Refactor the cross-compilation infrastructure to rely on the standard
CMAKE_CROSSCOMPILING_EMULATOR variable instead of the custom
CROSSCOMPILING_PATH environment hack.

Key changes:
- Removed `ENVIRONMENT "${CROSSCOMPILING_PATH}"` from all test definitions.
- Updated custom commands (e.g., H5match_types, H5_gen) to invoke the
  emulator explicitly when cross-compiling.
- Updated ConfigureChecks.cmake and HDF5UseFortran.cmake to enable
  `try_run` checks when an emulator is defined.
- Added config/toolchain/mingw-w64-x86-64-wine.sh wrapper to automatically
  locate MinGW runtime libraries (like libgfortran) for Wine execution.
- Cleaned up toolchain files to remove hardcoded emulator paths, deferring
  configuration to the build environment.

* Add Doxygen setup that results in missing Doygen documentation. (#6217)

* Added setup-doxygen action in ctest.yml Ubuntu gcc workflow.
* Also added actions/checkout for setup-doxygen.

* Fixes link checker failure (#6219)

Removed https:// as a workaround to avoid error by the link checker.

* Remove force-setting of ZLIB_USE_EXTERNAL / SZIP_USE_EXTERNAL (#6222)

Removes the force-setting of ZLIB_USE_EXTERNAL and SZIP_USE_EXTERNAL to
ON when HDF5_ALLOW_EXTERNAL_SUPPORT is GIT or TGZ so that zlib and
szip can be independently built from the system or externally as desired

* Truncate Subfiling VFD's stub file when truncating subfiles (#6210)

Ensure that the Subfiling VFD's stub file gets truncated when subfiles are
being truncated to avoid a potentially unreadable file when the EOF doesn't
match the stored EOF value

Co-authored-by: Larry Knox <lrknox@hdfgroup.org>

* Add CMake function to extract pkg-config info from libraries (#6220)

* Consistent extension for C++ (#6214)

Except for this file, all use cpp instead of cxx. No obvious reason why
the same file types should have different extensions.

* Enable Windows ARM64 CTest CI for release binaries (#6177)

* ci: add Windows ARM64 MSVC CTest job

* ci: add MSYS2 clangarm64 build on Windows ARM64

* cmake: add MSVC ARM64 presets for Windows

* zlib: fix MSVC static library flags for ARM64 builds

* Renamed .hxx file to .h and updated the #include for it.

* Committing clang-format changes

---------

Co-authored-by: Scot Breitenfeld <brtnfld@hdfgroup.org>
Co-authored-by: bmribler <39579120+bmribler@users.noreply.github.com>
Co-authored-by: Gerd Heber <gheber@hdfgroup.org>
Co-authored-by: jhendersonHDF <jhenderson@hdfgroup.org>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Julien Schueller <schueller@phimeca.com>
Co-authored-by: Martin Diehl <mail@martin-diehl.net>
Co-authored-by: Harish RS <harish.rajaselvan@multicorewareinc.com>
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

java/hdf/hdf5lib/H5.java

@@ -133,7 +133,7 @@ import org.slf4j.LoggerFactory;
  * </tr>
  * <tr>
  * <td>void * <br />
- * (i.e., pointer to `Any')</td>
+ * (i.e., pointer to Any)</td>
  * <td>Special -- see @ref HDFARRAY</td>
  * </tr>
  * </table>
@@ -194,11 +194,11 @@ import org.slf4j.LoggerFactory;
  * @endcode
  *
  * <p>
- * where ``void *'' means that the data may be any valid numeric type, and is a contiguous block of bytes that
+ * where "void *" means that the data may be any valid numeric type, and is a contiguous block of bytes that
  * is the data for a multi-dimensional array. The other parameters describe the dimensions, rank, and datatype
  * of the array ondisk (source) and in memory (destination).
  * <p>
- * For Java, this ``ANY'' is a problem, as the type of data must always be declared. Furthermore,
+ * For Java, this "ANY" is a problem, as the type of data must always be declared. Furthermore,
  * multidimensional arrays are definitely <i>not</i> laid out contiguously in memory. It would be infeasible
  * to declare a separate routine for every combination of number type and dimensionality. For that reason, the
  * @ref HDFARRAY <b>HDFArray</b> class is used to discover the type, shape, and
@@ -206,7 +206,7 @@ import org.slf4j.LoggerFactory;
  * static  C order.
  * <p>
  * The upshot is that any Java array of numbers (either primitive or sub-classes of type <b>Number</b>) can be
- * passed as an ``Object'', and the Java API will translate to and from the appropriate packed array of bytes
+ * passed as an "Object", and the Java API will translate to and from the appropriate packed array of bytes
  * needed by the C library. So the function above would be declared:
  *
  * @code

java/src-jni/hdf/hdf5lib/H5.java

@@ -108,7 +108,7 @@ import org.slf4j.LoggerFactory;
  * </tr>
  * <tr>
  * <td>void * <br />
- * (i.e., pointer to `Any')</td>
+ * (i.e., pointer to `Any`)</td>
  * <td>Special -- see @ref HDFARRAY</td>
  * </tr>
  * </table>
@@ -181,7 +181,7 @@ import org.slf4j.LoggerFactory;
  * static native C order.
  * <p>
  * The upshot is that any Java array of numbers (either primitive or sub-classes of type <b>Number</b>) can be
- * passed as an ``Object'', and the Java API will translate to and from the appropriate packed array of bytes
+ * passed as an `Object`, and the Java API will translate to and from the appropriate packed array of bytes
  * needed by the C library. So the function above would be declared:
  *
  * @code