Updates from macOS testing

[mathomp4]

In my current testing with spack-stack and macOS, I found I needed to update several packages used in GEOS. This PR is broader than the title suggests — summary below.

NAG compiler support (macOS/Darwin)

These changes were needed to build with the NAG Fortran compiler on macOS:

• esmf: Fix compiler detection to use spec["fortran"].name instead of self.pkg.compiler.name for NAG
• hdf5: Add nag_macos_linker.patch to fix Apple linker flags (-current_version/-compatibility_version) when building with NAG on Darwin (@1.12.0:1.14.99 %nag platform=darwin)
• nag: Add pic_flag = "-PIC"
• netcdf-fortran: Add fix_darwin_libtool post-configure hook that rewrites libtool linker flags for %nag platform=darwin (install name, compatibility version, -Xlinker passthrough)

libiconv

Updated by pulling from upstream spack (official/develop), plus additional fixes:

• Remove platform=darwin conflict — libiconv can now build on macOS
• Add loop_wchar_9eb508.patch for @:1.17: removes implicit mbrtowc declaration that fails as a prototype error on newer compilers
• Add workaround for Intel oneAPI icx gl_cv_func_working_error configure infinite-loop bug (affects %oneapi@:2025; see Intel community post)
• Remove macOS-specific determine_version / external iconv detection logic (no longer needed)

openblas

Updated by pulling from upstream spack (official/develop), plus additional fixes:

• New versions: 0.3.30, 0.3.32; deprecate versions 0.3.19 and older
• AOCC compiler detection patches for multiple version ranges (@0.3.21:0.3.26, @0.3.27, @0.3.28:)
• Apple LTO fix patch for @0.3.30 platform=darwin (handles Xcode 16+ with [ -ge ] instead of ifeq)
• blas_normalize_test_symbols.patch for MSVC: adds -DNOCHANGE to normalize test symbol mangling
• New +static variant for building static libraries
• fortran dependency is now conditional on +fortran or @:0.3.20 (not unconditional)
• ARM64 macOS with GCC: add NO_SVE=1 for dynamic arch builds
• Sequential make targets (libs, netlib, shared) to avoid race conditions in parallel builds
• find_headers now uses recursive=True
• CMake build system: add ~ilp64 and symbol_suffix=none requirements; add +static support

openmpi

Updated by pulling from upstream spack (official/develop), plus:

• New versions: 5.0.9, 5.0.10
• Add add_string.patch: missing #include <string.h> in ROCm accelerator module
• Add fix_fs_gpfs_file_set_info.patch: GPFS replication struct compatibility fix for gpfsSetReplicationX (see ompi #13313)

---

This is still in draft as testing is ongoing. @climbfuji — would appreciate a review, especially on the openmpi changes which diverge significantly from the previous version.

[climbfuji]

I don't see any problem with these updates. Let's make sure they work as expected in spack-stack CI. I may also want to test on my WSL2 laptops.

[mathomp4]

I don't see any problem with these updates. Let's make sure they work as expected in spack-stack CI. I may also want to test on my WSL2 laptops.

Should I make a PR to spack-stack updating the submodule to see how the CI responds?

[climbfuji]

I don't see any problem with these updates. Let's make sure they work as expected in spack-stack CI. I may also want to test on my WSL2 laptops.

Should I make a PR to spack-stack updating the submodule to see how the CI responds?

Yes please

[mathomp4]

I don't see any problem with these updates. Let's make sure they work as expected in spack-stack CI. I may also want to test on my WSL2 laptops.

Should I make a PR to spack-stack updating the submodule to see how the CI responds?

Yes please

@climbfuji I just did JCSDA/spack-stack#1990 but I might have done the git wrong. Weirdly, I see your p4est and py_protobuf changes in that test PR? I mean, my changes are there too but...huh.

[climbfuji]

I don't see any problem with these updates. Let's make sure they work as expected in spack-stack CI. I may also want to test on my WSL2 laptops.

Should I make a PR to spack-stack updating the submodule to see how the CI responds?

Yes please

@climbfuji I just did JCSDA/spack-stack#1990 but I might have done the git wrong. Weirdly, I see your p4est and py_protobuf changes in that test PR? I mean, my changes are there too but...huh.

because JCSDA/spack-stack#1988 isn't merged yet

[climbfuji]

Is this PR a draft until the upstream PRs are all merged?

[mathomp4]

Is this PR a draft until the upstream PRs are all merged?

Oh sorry. I guess I forgot this was draft. I think this is good for GCC at least. Let me try one more build with it to make sure GCC doesn't fall apart.

NAG is still...exciting.