Update hdf5 to 2.1.0 and parallel-netcdf to 1.14.1; require +fix_rt_linkage for intel-oneapi-compilers

[mathomp4]

Description

Update to hdf5 2.1.0 and parallel-netcdf 1.14.1

Because the new parallel-netcdf is missing the internal patch to link against libintlc.so instead of libirc.so, we now enforce = require the variant +fix_rt_linkage for intel-oneapi-compilers. What this variant does is patching the Intel runtime libraries when installed in the environment by Spack with the usual bug fix for partially missing/unresolved symbols in libirc.so and libimf.so. This variant is declared for intel-oneapi-compilers but affects the intel-oneapi-runtime package - i.e. it applies to both external and spack-built intel-oneapi-compilers.

Site maintainers must add +fix_rt_linkage to their external intel-oneapi-compilers package or they will hit the following error during concretization:

==> Error: failed to concretize [...] for the following reasons:
     1. Only external, or concrete, compilers are allowed for the fortran language

No other action is required. The only effect of the +fix_rt_linkage variant is that libirc.so and libimf.so are patched on the fly when being copied from the original Intel installation to the Spack environment runtime directory.

The CI workflows are updated accordingly, and the now unnecessary tool util/check_libirc.sh is removed.

Dependencies

None

Issues addressed

Closes #1822

Applications affected

Any application using hdf5 → netcdf, esmf, etc.

Systems affected

None directly

Testing

• CI: Note whether the automatic tests (GitHub actions tests that run automatically for every commit) pass or not
  • GitHub actions CI tests pass
  • GitHub actions CI tests do not pass (provide explanation)
  • GitHub actions CI tests skipped (provide explanation if necessary)
• New tests added: List and describe any new tests added to GitHub actions
  • ...
• Additional testing: Add information on any additional tests conducted
  • ...

Checklist

• This PR addresses one issue/problem/enhancement or has a very good reason for not doing so.
• These changes have been tested on the affected systems and applications.
• All dependency PRs/issues have been resolved and this PR can be merged.
• All necessary updates to the documentation (spack-stack wiki) will be made when this PR is merged

[climbfuji]

@mathomp4 Can you pull in the latest develop code, please? Maybe this fixes the CI errors.

[mathomp4]

@mathomp4 Can you pull in the latest develop code, please? Maybe this fixes the CI errors.

Done.

[srherbener]

Just want to double check. Doesn't the netcdf-c library need to be upgraded to at least 4.10.0 for hdf5 2.x compatibility. Check out the release notes: https://github.com/Unidata/netcdf-c/releases under the v4.10.0 section.

If you agree, I would vote for netcdf-c 4.10.1 since it's the latest.

Thanks!

[mathomp4]

Just want to double check. Doesn't the netcdf-c library need to be upgraded to at least 4.10.0 for hdf5 2.x compatibility. Check out the release notes: Unidata/netcdf-c/releases under the v4.10.0 section.

If you agree, I would vote for netcdf-c 4.10.1 since it's the latest.

Thanks!

Well huh. That is interesting. I've done all my testing with netcdf-c@4.9.2 and GEOS has been happy.

I can try it out and see. @climbfuji Thoughts?

[mathomp4]

Related #2055

[climbfuji]

Just want to double check. Doesn't the netcdf-c library need to be upgraded to at least 4.10.0 for hdf5 2.x compatibility. Check out the release notes: Unidata/netcdf-c/releases under the v4.10.0 section.
If you agree, I would vote for netcdf-c 4.10.1 since it's the latest.
Thanks!

Well huh. That is interesting. I've done all my testing with netcdf-c@4.9.2 and GEOS has been happy.

I can try it out and see. @climbfuji Thoughts?

I am looking at the issue in netcdf-c Unidata/netcdf-c#3246 and the pull request Unidata/netcdf-c#3247. I am not sure if these bug fixes are critical. Mostly they are about the parallel tests.

I would say continue this update to hdf5 version 2 and parallel-netcdf 1.14.1. We can all check our applications and if we find critical issues OR we have time left, we can update netcdf-c.

[mathomp4]

I would say continue this update to hdf5 version 2 and parallel-netcdf 1.14.1. We can all check our applications and if we find critical issues OR we have time left, we can update netcdf-c.

Okay. I suppose no one needs #2055 yet. Maybe for 2.3 we move to netcdf-c 4.10.1 and netcdf-fortran 4.9.4 (or whatever is newest then).

If I have time tomorrow, I'll do a test build with the newer versions just to see:

1. Do they build with spack-stack?
2. Does GEOS (at least) freak out with them?

[mathomp4]

I would say continue this update to hdf5 version 2 and parallel-netcdf 1.14.1. We can all check our applications and if we find critical issues OR we have time left, we can update netcdf-c.

Okay. I suppose no one needs #2055 yet. Maybe for 2.3 we move to netcdf-c 4.10.1 and netcdf-fortran 4.9.4 (or whatever is newest then).

If I have time tomorrow, I'll do a test build with the newer versions just to see:

1. Do they build with spack-stack?
2. Does GEOS (at least) freak out with them?

Well, the answer to 1 is not without changes. I know we'd at least need to fix up the parallelio package (or wait for @jedwards4b to release a compatible version). I don't think it's a hard fix to figure out, but it's enough that we'd need more time than we have for spack-stack 2.2.

[climbfuji]

We can also backport the small update to the CMakeLists.txt file in netcdf-c that deals with detecting HDF5 PARALLEL. We don't need the test fixes.

[srherbener]

Thank you @mathomp4 and @climbfuji for checking the netcdf compatibility question. Given that we haven't seen any issues around this crop up yet, I suspect that the hdf5 2.x compatibility fix in netcdf-c 4.10.0 is limited in scope enough that the risk is low to stay with netcdf-c 4.9.2. Perhaps at this point we should proceed with netcdf-c 4.9.2, possibly add @climbfuji's suggestion with backporting the fix that was done in 4.10.0, and make sure we test thoroughly once we have the 2.2 release branch ready. In other words, I feel that upgrading to netcdf-c 4.10.x now is not worth the impact on the spack-stack-2.2 schedule.

[climbfuji]

@mathomp4 I updated the PR description for my changes that you merged in yesterday.

[jim-p-w]

Can someone elaborate about exactly where in my packages_oneapi-2025.3.2.yaml file I put the +fix_rt_linkage specification? Does it go immediately after the externals: designator as below?

packages:
   intel-oneapi-compilers:
      externals:
      +fix_rt_linkage

[climbfuji]

Can someone elaborate about exactly where in my packages_oneapi-2025.3.2.yaml file I put the +fix_rt_linkage specification? Does it go immediately after the externals: designator as below?

packages:
   intel-oneapi-compilers:
      externals:
      +fix_rt_linkage

See

spack-stack/configs/sites/tier1/atlantis/packages_oneapi-2026.0.0.yaml

Line 15 in a141693

- spec: intel-oneapi-compilers@2026.0.0 +fix_rt_linkage

for example

[climbfuji]

Thank you @mathomp4 and @climbfuji for checking the netcdf compatibility question. Given that we haven't seen any issues around this crop up yet, I suspect that the hdf5 2.x compatibility fix in netcdf-c 4.10.0 is limited in scope enough that the risk is low to stay with netcdf-c 4.9.2. Perhaps at this point we should proceed with netcdf-c 4.9.2, possibly add @climbfuji's suggestion with backporting the fix that was done in 4.10.0, and make sure we test thoroughly once we have the 2.2 release branch ready. In other words, I feel that upgrading to netcdf-c 4.10.x now is not worth the impact on the spack-stack-2.2 schedule.

Yeah, if we don't worry about the test_nc4 update, then all we need to pick up from https://github.com/Unidata/netcdf-c/pull/3247/changes is this change in cmake/dependencies.cmake:

  set(HDF5_PARALLEL ${HDF5_IS_PARALLEL})

+   ## Adjust for HDF5 2.0.0, which changed to HDF5_PROVIDES_PARALLEL
+   if(NOT HDF5_PARALLEL)
+     set(HDF5_PARALLEL ${HDF5_PROVIDES_PARALLEL})
+   endif(NOT HDF5_PARALLEL)

[eap]

I'm more than a little confused by this change and your wording here.

Site maintainers must add +fix_rt_linkage to their external intel-oneapi-compilers package or they will hit the following error during concretization:

This almost sounds like you're just saying that we need a spec fix, but how does the actual fix get applied to the intel-oneapi-compilers package when referenced as an external?

Edit:

are patched on the fly when being copied from the original Intel installation to the Spack environment runtime directory.".

ohhh... ok so spack does the fixing because external compilers are vendored and spack uses this variant to fix the vendored version of the external compiler. Yes?

[climbfuji]

I'm more than a little confused by this change and your wording here.

Site maintainers must add +fix_rt_linkage to their external intel-oneapi-compilers package or they will hit the following error during concretization:

This almost sounds like you're just saying that we need a spec fix, but how does the actual fix get applied to the intel-oneapi-compilers package when referenced as an external?

Edit:

are patched on the fly when being copied from the original Intel installation to the Spack environment runtime directory.".

ohhh... ok so spack does the fixing because external compilers are vendored and spack uses this variant to fix the vendored version of the external compiler. Yes?

Almost. spack copies runtime libraries from the compiler installation (internal or external) as intel-oneapi-runtime package. The latter is always spack-built, not external. We hijack this process with patchelf with the variant +fix_rt_linkage. Because of how the runtime and compilers packages are designed (not our choice, that is Spack), the variant must be declared for the compiler, spack-built or external.