Fix netcdf4/h5py dimension scales on emscripten

[MMesch]

Summary

Fixes the runtime failure xarray.open_dataset(...) → netCDF4.Dataset → nc_open → H5DSis_scale → Dynamic linking error: cannot resolve symbol H5DSis_scale in the browser, and the follow-on RuntimeError: ring type mismatch occurred for cache entry that surfaces once H5DSis_scale is reachable.

Four package commits along the dependency chain:

• hdf5: 1.12.3 → 1.14.6, plus two patches (see complications).
• h5py: rebuild against 1.14.6, drop the ctypes.CDLL preload in __init__.py.
• libnetcdf: skip the DAOS-container check under __EMSCRIPTEN__.
• netcdf4: add -lhdf5_hl to LDFLAGS.

variant.yaml bumped: hdf5: 1.14.6, libnetcdf: 4.10.1.

<This was assisted by: Opus 4.7>

Complications

1. HDF5 1.14.6 uses feclearexcept(FE_INVALID) in H5Tinit_float.c. Emscripten's <bits/fenv.h> defines only rounding modes and FE_ALL_EXCEPT=0; FE_INVALID is not declared because WASM has no FP exception flags. Guarded with #ifdef FE_INVALID.

2. Emscripten's dynamic loader dedupes shared libraries by string identity of the NEEDED entry, not by realpath. With SOVERSION set, libhdf5_hl.so records NEEDED libhdf5.so.310.5.1, while -lhdf5 in consumers records NEEDED libhdf5.so. Both paths resolve to the same file via symlinks, but the loader treats them as distinct and loads libhdf5.so twice, each with its own bss segment. That produces two copies of H5CX_head_g (a file-static in H5CX.c) and every other libhdf5 global. When a call chain crosses between the two instances the metadata-cache "ring" invariant fires and any HL call after H5Aexists aborts. Confirmed by tracing patched H5CX_set_ring/push/pop/get_ring and observing two distinct &head_g addresses in the same process (0x2e31be0 and 0x38c9f40). Fix: skip set_target_properties(... VERSION SOVERSION) under EMSCRIPTEN in config/cmake/HDF5Macros.cmake so every consumer sees the same bare libhdf5.so NEEDED string. Same class of hazard may affect other C libraries in emscripten-forge that ship a versioned SONAME.

3. netcdf-c 4.10.1 references listxattr from libdispatch/dinfermodel.c inside the DAOS-container probe, guarded by HAVE_SYS_XATTR_H. Emscripten's <sys/xattr.h> declares listxattr but the runtime doesn't implement it, so the built .so fails to load. configure.ac has zero DAOS knobs (no --disable-daos), so patch the source to early-return NC_ENOTNC under __EMSCRIPTEN__. Attempting ac_cv_header_sys_xattr_h=no produced garbled compile errors in the surrounding isdaoscontainer() function under -std=gnu23 and was abandoned.

4. The libnetcdf variant pin was 4.9.3 even though the recipe carries version 4.10.1. Locally, that forced netcdf4's solver to reject 4.10.1 and pull 4.9.3 from upstream — which had been compiled against HDF5 1.12.3 headers and aborted at runtime against the 1.14.6 library ("Headers are 1.12.3, library is 1.14.6"). Bumped the pin to 4.10.1.

Test plan

• hdf5 builds cleanly with both patches
• h5py builds against 1.14.6, all 4 tests pass (import, usage, version, dimscales)
• libnetcdf builds cleanly
• netcdf4 builds cleanly, all 3 tests pass (versions, netcdf3 round-trip, netcdf4 round-trip)

[MMesch]

@IsabelParedes , waiting for your thoughts on this now. After discussing with @DerThorsten these are some points to consider:

• the feclearexcept(FE_INVALID) issue is solved upstream in hdf5 2.x.
• the deduplication problem should be solved generally. But we can use the patch here as hot fix and move ahead with this recipe more quickly.
• the netcdf updates could be split out in a separate PR

[IsabelParedes]

the netcdf updates could be split out in a separate PR

This would be nice. Thanks!