Publish libhdf5 builds for more recent Emscripten versions

[LTLA]

I'm assuming that you managed to convince your admins in #2, given that v0.2.1_3.1.8 now exists.

Anyway, can we get some builds for some more recent Emscripten versions? Looks like 3.1.31 is out, and I'm getting linking errors if I use the current HDF5 binaries due to some references to some missing symbols.

Note that 1.10.8 might need to be removed - it was failing with 3.1.25, so I guess it'll continue to fail with the latest Emscripten. Otherwise, it seems to build fine, e.g., https://github.com/LTLA/libhdf5-wasm/releases/tag/v0.2.0-test_3.1.31.

[bmaranville]

After a very long delay, I'm working on this... would you have any objection to always building the library with BUILD_SHARED_LIBS=ON?

EDIT: I'm realizing that flag may not actually do anything... maybe my issues were coming from using a very old build of libhdf5-wasm

[LTLA]

I'm not sure. What's the current default?

I had been under the impression that we needed the static *.a libs to ensure that the HDF5 libraries was actually included in the final Wasm binary. It's not clear to me how shared linking even works with Emscripten; seems non-obvious.

[bmaranville]

I think the current default is ON (from the HDF5 CMake setup). Somewhere in the release docs for 1.8 it mentions that the default was changed because with ON it builds both the static and shared libraries.

Also I noticed that the (relatively new) 1.10.10 release will build with new emscripten versions, so I will switch to that from 1.10.8

[bmaranville]

I keep getting errors like this on the auto-release:

It's not a big issue - I will just upload that version manually, but I was wondering if you had seen this.

[LTLA]

Hm. Never seen that before. Looking around, it might be the GitHub API itself (e.g., actions/upload-artifact#116).

[bmaranville]

I made a release, which hopefully addresses this issue. Sorry for the long delay!

[bmaranville]

I just changed the way I'm packaging at the end - I'm using cpack with the HDF5-provided cpack configuration. It seems to work well and I don't need to inject a new CMakeLists.txt to the artifact - a hdf5-config.cmake file is provided automatically, which makes find_package(HDF5 REQUIRED CONFIG) work properly (see the README.md for details).

The new release v0.4.0_3.1.43 uses the new package layout.

EDIT: after testing the version built by github actions I see that libz and libsz are not being linked correctly, and I deleted the release. Hopefully it will be fixed soon.

[LTLA]

Neat, I didn't know about CPack. I'm currently just FetchContent'ing all my dependencies, which also works pretty well, but does require me to override some internal find_package() calls in my HDF5-dependent libraries. Might think about removing some of the workarounds in my builds if find_package(HDF5) works.

[shimwell]

EDIT: after testing the version built by github actions I see that libz and libsz are not being linked correctly, and I deleted the release. Hopefully it will be fixed soon.

I'm seeing some errors that look like missing libz libsz related over here and just wanted to check if release v0.4.2 fixed that issue.

[agriyakhetarpal]

Hi all, https://github.com/emscripten-core/emscripten/releases/tag/3.1.68 is now out – if it's possible, it would be great to do this (and for an updated version of libhdf5: https://github.com/HDFGroup/hdf5/releases/tag/hdf5_1.14.5 was recently released, too). A gentle ping to those active in the development of this repository and for those subscribed here!

I've also seen HDFGroup/hdf5#3682. If the number of changes or patches to be applied to libhdf5 are not intrusive or complicated, it would be nice to upstream the CMake configuration so that they can do this (which I could do or help with doing).

[LTLA]

FYI @bmaranville I moved the docker image repo to https://github.com/kanaverse/emcmake-docker with the latest Emscripten + CMake. The old Docker images will still work but you could also just update to the latest version of the image here. As for the build; I was trying it a few days ago and it seems that Emscripten doesn't define the FE_INVALID macro that was added to the HDF5 source late last year. I had to do some fiddling to get it to skip that part.

[bmaranville]

That's too bad about the fiddling. If we want to try to upstream the libhdf5 build process for emscripten targets, it's bad that it keeps getting harder.

[bmaranville]

@LTLA do you feel like the hdf5 sources should be updated to remove FE_INVALID? If it's not always defined in standards-compliant C then maybe it shouldn't be used?

[LTLA]

IMO seems reasonable enough to request for an #ifdef FE_INVALID around that code so we don't have to mess with the sources. Well, it can't hurt to ask; I can post an issue on the weekend if you don't get to it first.

[LTLA]

Posted at HDFGroup/hdf5#4952, let's see what they say.