What’s happening now
pyissm imports netCDF4 (pyissm/model/io.py does import netCDF4 as nc)
netCDF4 loads its compiled extension (netCDF4/_netCDF4*.so)
that extension links against Conda’s libhdf5_hl.so.310
but the HDF5 already loaded in the process is NOT the one that libhdf5_hl was built against, so a symbol it expects is missing:
libhdf5_hl.so.310: undefined symbol: H5T_IEEE_F16BE_g
This happens because you’re trying to make ISSM/PETSc happy by forcing/using the Spack MPI-HDF5, while also trying to keep Conda netCDF4 (which expects Conda HDF5). Those two HDF5 stacks are not ABI-compatible in one Python process.One process can only safely use one HDF5 family (headers + libs + plugins) across all compiled packages.
What’s happening now
pyissm imports netCDF4 (pyissm/model/io.py does import netCDF4 as nc)
netCDF4 loads its compiled extension (netCDF4/_netCDF4*.so)
that extension links against Conda’s libhdf5_hl.so.310
but the HDF5 already loaded in the process is NOT the one that libhdf5_hl was built against, so a symbol it expects is missing:
libhdf5_hl.so.310: undefined symbol: H5T_IEEE_F16BE_g
This happens because you’re trying to make ISSM/PETSc happy by forcing/using the Spack MPI-HDF5, while also trying to keep Conda netCDF4 (which expects Conda HDF5). Those two HDF5 stacks are not ABI-compatible in one Python process.One process can only safely use one HDF5 family (headers + libs + plugins) across all compiled packages.