ci: add big-endian (s390x) build and test workflow via QEMU#6367
ci: add big-endian (s390x) build and test workflow via QEMU#6367brtnfld wants to merge 19 commits into
Conversation
Adds bigendian.yml using jirutka/setup-alpine with arch: s390x to run builds and tests under an Alpine Linux s390x environment (big-endian). Wires it into call-workflows.yml alongside the existing i386 job.
|
It takes too long to run for a PR check; it should be moved to a daily test. |
test/API/H5_api_dataset_test.c: H5Tenum_insert requires a value pointer matching the base type size (int/uint32_t = 4 bytes). Passing &i where i is size_t (8 bytes) causes the function to read the high 4 bytes on big-endian systems, which are always zero for small i, resulting in duplicate enum member errors. Fix by using a properly-typed local variable for both the native (int) and non-native (uint32_t) enum inserts. bigendian.yml: add --timeout 1800 to ctest to accommodate the slower execution speed of QEMU s390x emulation.
This test consistently hits the 1800s per-test ceiling under QEMU s390x emulation (the h5dump command itself returns 0; the image dataset creation is simply too slow). Exclude it rather than inflating the timeout further.
|
Crashes before any output due to missing libquadmath.so on Alpine s390x (REAL(16) is compiled in but libquadmath is not available as a package). To be investigated separately.
|
@brtnfld , can you patch this and include image test? |
There was a problem hiding this comment.
2 more changes are desired:
- See #6367 (comment) .
- Use
uraimo/run-on-arch-actioninstead ofjirutka/setup-alpine. Then, fortran test will also pass.
Gemini's explanation:
Recent issues in the jirutka/setup-alpine repository suggest that while s390x is supported, there have been sporadic "segmentation faults" and "Illegal instruction" errors tied to how it installs apk-tools during the initial setup on certain architectures.
Recommendation
If you need stability for s390x: Stick with uraimo/run-on-arch-action. Its Docker-based approach is better at isolating the emulation layer from the host's quirks.
If you need speed and only use x86/ARM: jirutka/setup-alpine is significantly faster because it doesn't have the overhead of Docker image layers, but it is more sensitive to the host environment.
… tests Replace jirutka/setup-alpine with uraimo/run-on-arch-action for more stable s390x QEMU emulation via Docker. Enable FORTRAN_testhdf5_fortran by removing it from the ctest exclusion list.
|
QEMU instability on GitHub-hosted runners seems to be an issue. Neither Alpine nor Ubuntu made a difference. At this point, uraimo/run-on-arch-action is not reliable enough for compiling HDF5 on s390x via QEMU on these runners. |
|
I see a red again if you revert to alpine after 2 greens with |
The h5ex_image2BE.ddl expected output was updated to H5T_STD_U8BE in eb535be, so there is no longer a need to skip H5_H5DUMP-h5ex_image2.
Temporary: allows the workflow to run automatically on push to this branch (and provides a Release fallback when build_mode input is absent). Remove the push trigger before merging.
Summary
.github/workflows/bigendian.yml: a reusableworkflow_calljob that builds and tests HDF5 on Alpine Linuxs390x(IBM Z, big-endian) usingjirutka/setup-alpinewith QEMU user-space emulationcall-workflows.ymlascall-release-cmake-bigendianalongside the existingi386jobpython3 -c "assert sys.byteorder == 'big'") to fail fast if endianness is wrongDesign notes
i386.ymlpattern — same action, same pinned hash, same CMake flags--parallel 2/ctest --parallel 2since s390x emulation is slower than native x86Test plan
bigendian.ymljob appears in the Actions tab on a push/PR todevelopConfirmed big-endianctestpass without failures