Skip to content

ci: add big-endian (s390x) build and test workflow via QEMU#6367

Open
brtnfld wants to merge 19 commits into
HDFGroup:developfrom
brtnfld:feature/ci-bigendian-s390x
Open

ci: add big-endian (s390x) build and test workflow via QEMU#6367
brtnfld wants to merge 19 commits into
HDFGroup:developfrom
brtnfld:feature/ci-bigendian-s390x

Conversation

@brtnfld
Copy link
Copy Markdown
Collaborator

@brtnfld brtnfld commented Apr 15, 2026

Summary

  • Adds .github/workflows/bigendian.yml: a reusable workflow_call job that builds and tests HDF5 on Alpine Linux s390x (IBM Z, big-endian) using jirutka/setup-alpine with QEMU user-space emulation
  • Wires it into call-workflows.yml as call-release-cmake-bigendian alongside the existing i386 job
  • Includes a sanity assertion (python3 -c "assert sys.byteorder == 'big'") to fail fast if endianness is wrong

Design notes

  • Modeled directly after the existing i386.yml pattern — same action, same pinned hash, same CMake flags
  • Fortran, Java, C++, ZLIB, SZIP, and plugin support are disabled to keep the emulated build lean; the goal is endianness correctness, not full feature coverage
  • Parallelism capped at --parallel 2 / ctest --parallel 2 since s390x emulation is slower than native x86

Test plan

  • Verify the bigendian.yml job appears in the Actions tab on a push/PR to develop
  • Confirm the "Verify big-endian" step prints Confirmed big-endian
  • Confirm build and ctest pass without failures

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.
@brtnfld
Copy link
Copy Markdown
Collaborator Author

brtnfld commented Apr 15, 2026

It takes too long to run for a PR check; it should be moved to a daily test.

brtnfld added 2 commits April 15, 2026 14:09
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.
Comment thread .github/workflows/bigendian.yml Outdated
@github-project-automation github-project-automation Bot moved this from To be triaged to In progress in HDF5 - TRIAGE & TRACK Apr 15, 2026
@hyoklee
Copy link
Copy Markdown
Member

hyoklee commented Apr 16, 2026

	2600 - FORTRAN_testhdf5_fortran (Failed)

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.
hyoklee
hyoklee previously approved these changes Apr 16, 2026
@hyoklee
Copy link
Copy Markdown
Member

hyoklee commented Apr 16, 2026

@brtnfld , can you patch this and include image test?

--- a/HDF5Examples/C/HL/tfiles/h5ex_image2BE.ddl
+++ b/HDF5Examples/C/HL/tfiles/h5ex_image2BE.ddl
@@ -33878,7 +33878,7 @@ GROUP "/" {
       }
    }
    DATASET "image8bit" {
-      DATATYPE  H5T_STD_U8LE
+      DATATYPE  H5T_STD_U8BE
       DATASPACE  SIMPLE { ( 400, 300 ) / ( 400, 300 ) }
       DATA {
       (0,0): 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
@@ -41397,7 +41397,7 @@ GROUP "/" {
       }
    }
    DATASET "palette" {
-      DATATYPE  H5T_STD_U8LE
+      DATATYPE  H5T_STD_U8BE
       DATASPACE  SIMPLE { ( 256, 3 ) / ( 256, 3 ) }
       DATA {
       (0,0): 0, 0, 255,

bmribler
bmribler previously approved these changes Apr 16, 2026
Copy link
Copy Markdown
Member

@hyoklee hyoklee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 more changes are desired:

  1. See #6367 (comment) .
  2. Use uraimo/run-on-arch-action instead of jirutka/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.

brtnfld added 2 commits April 22, 2026 10:50
… 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.
@brtnfld
Copy link
Copy Markdown
Collaborator Author

brtnfld commented Apr 22, 2026

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.

@hyoklee
Copy link
Copy Markdown
Member

hyoklee commented Apr 23, 2026

I see a red again if you revert to alpine after 2 greens with uraimo.

brtnfld added 3 commits May 19, 2026 13:45
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In progress

Development

Successfully merging this pull request may close these issues.

4 participants