HDF5: Build via cmake

[eschnett]

No description provided.

[eschnett]

@mkitti Do you want to have a look at this PR?

[mkitti]

This looks promising. If I understand, we are mainly patching for Fortran cross-compilation. Otherwise, the cmake builds look pretty straightforward.

In the future, I would like to separate out the base C library builds and the Fortran support since the latter is much more involved.

I have not checked with @derobins recently about cross compilation efforts upstream. Last, I knew there were issues with the nAG Fortran compiler, which we do not use.

[derobins]

The problem with Fortran cross-compilation is that we have to determine the integer kinds at configure time, which involves running a program and inspecting the output. This is true in both CMake and the Autotools.

The problem with the NAG compiler (among others) wasn't due to cross compilation per se, it was due to floating-point type initialization that would raise floating point exceptions as it worked to determine the behavior of floating point on the system. The FPEs we raised are ignored by default on most compilers, but NAG is fussy out of the box and other compilers had problems when all the exceptions are caught. We fixed that a few versions back by disabling floating point exceptions while we introspect the types (and restoring the original setting when we're done).

[eschnett]

https://github.com/HDFGroup/hdf5/releases/tag/hdf5_1.14.6

[giordano]

https://buildkite.com/julialang/yggdrasil/builds/17781 failed

[eschnett]

The error message is from ccache, which is weird:

ccache: error: execute_noreturn of /opt/x86_64-linux-musl/bin/clang failed: No such file or directory

The build succeeds locally. Just retry?

[giordano]

@maleadt I still believe all these issues are filesystem-related. I don't have other explanations for files occasionally not being found on disk where they should be.

[giordano]

@eschnett this broke ABI of windows builds, because of course life is terrible and just changing build system results in different sonames for built libraries: https://discourse.julialang.org/t/hdf5-is-broken-on-windows/125988. See how the soname changed in JuliaBinaryWrappers/HDF5_jll.jl@3f7b3cd#diff-b36a91c6c88efa5bc40d21995d64e8e7e66c7508a2bb5630d057acc70c9a09d2.

Note also how the soname of libhdf5_hl_fortran for all platforms changed from libhdf5hl_fortran to libhdf5_hl_fortran. Why we can't have nice things?

[eschnett]

The libhdf5_hl_fortran issue is a "problem" that the HDF5 developers "fixed" a few years ago, renaming the library. All build scripts now need to check which name is used. Since we map names to identifiers I thought we'd be somewhat immune to this renaming...

Of course this broke the Windows ABI! Why didn't I think of this myself. With just a bit of cleverness we could have so many more ABI breaks!

How do we fix this? Can one just symlink / hard link / rename / copy library files on Windows?

[giordano]

How do we fix this? Can one just symlink / hard link / rename / copy library files on Windows?

Symlinks don't make sense on Windows, we turn them into copies anyway, but that's a useless duplication. Renaming might be the easiest option, but I don't know if the package contains references to the "original" name. If that's also a problem, we may have to just declare the incompatibility in the registry

[joa-quim]

dlls cannot be renamed on Windows. Their names are burnt internally and software that depend on them don't let be fooled by renaming. Options seem to be the name renaming on build, or a new libnetcdf linked against this hdf version.

[mkitti]

Do we need to rebuild all the dependencies now?

[giordano]

Do we need to rebuild all the dependencies now?

No, that's out of the table. That's why I suggested fixing it in the registry.

[giordano]

Since no one else moved: JuliaRegistries/General#125412. I'd greatly appreciate if other people would do this kind of work, I'm one person, can't deal with possibly everything.

[giordano]

Since no one else moved part 2: #10559.