use qemu on github CI for ppc64le, s390x

[mattip]

• I updated the package version in pyproject.toml and made sure the first 3 numbers match git describe --tags --abbrev=8 in OpenBLAS at the OPENBLAS_COMMIT. If I did not update OPENBLAS_COMMIT, I incremented the wheel build number (i.e. 0.3.29.0.0 to 0.3.29.0.1)

Now that we have moved to cibuildwheel on linux, it should be easy to add ppc64le and s390x builds to the matrix. Let's see how long it takes to run. Travis CI is unstable, it would be nice to move off it.

[mayeut]

I wanted to check if something could be cross-build with clang but seeing QEMU was failing here, wanted to check that first.

• S390X: the samin/samax/damin/damax kernels are using the lper/ lpderinstructions which are not supported by QEMU (SIGILL triggered). Once those specific tests are disabled, everything else passes (when tests don't hang but it should be fix by update OpenBLAS version to v0.3.30-322-gef6f9762 #227 ? or another OpenBLAS upgrade).
  They can be disabled like the ones for loongarch64:

diff --git a/tools/build_steps.sh b/tools/build_steps.sh
index ee91642..c11ba72 100644
--- a/tools/build_steps.sh
+++ b/tools/build_steps.sh
@@ -220,9 +220,17 @@ EOF
         echo -n > utest/test_dsdot.c
         echo "Due to the qemu versions 7.2 causing utest cases to fail,"
         echo "the utest dsdot:dsdot_n_1 have been temporarily disabled."
+    elif [ "$plat" == "s390x" ]; then
+        sed -i 's/CTEST(samin, positive_step_1_N_70){/CTEST_SKIP(samin, positive_step_1_N_70){/g' ./utest/test_extensions/test_samin.c
+        sed -i 's/CTEST(samin, negative_step_1_N_70){/CTEST_SKIP(samin, negative_step_1_N_70){/g' ./utest/test_extensions/test_samin.c
+        sed -i 's/CTEST(damin, positive_step_1_N_70){/CTEST_SKIP(damin, positive_step_1_N_70){/g' ./utest/test_extensions/test_damin.c
+        sed -i 's/CTEST(damin, negative_step_1_N_70){/CTEST_SKIP(damin, negative_step_1_N_70){/g' ./utest/test_extensions/test_damin.c
+        echo "the utest samin/damin have been temporarily disabled."
+        echo "QEMU does not support the 'lper' /'lpdr' instructions used"
     fi
     if [ -n "$dynamic_list" ]; then
         CFLAGS="$CFLAGS -fvisibility=protected -Wno-uninitialized" \

• PPC64LE: OpenBLAS does not support customising the DYNAMIC_LIST which ends up including an x86_64 kernel...

The builds that did not hang on tests took around 3 hours: https://github.com/mayeut/openblas-libs/actions/runs/19394958005/job/55493703960

[mattip]

PPC64LE: OpenBLAS does not support customising the DYNAMIC_LIST which ends up including an x86_64 kernel

I see we are setting target="POWER8" but no explicit DYNAMIC_LIST. Should we set one?

Also: what happens when s390x does not actually assign a target, how does compilation work?

[mayeut]

Suggested change

local dynamic_list="POWER8 POWER10"

ppc64le does not support dynamic list

[mattip]

The README seems to imply that DYNAMIC_LIST is supported

For POWER, the list encompasses POWER6, POWER8 and POWER9. POWER10 is additionally available if a sufficiently recent compiler is used for the build.

[mayeut]

DYNAMIC_ARCH is supported with this list (depending on compiler), but user provided DYNAMIC_LIST is not supported (either on purpose or an oversight) in https://github.com/OpenMathLib/OpenBLAS/blob/develop/Makefile.system

[mattip]

Strange. Is there an open OpenBLAS issue about the missing DYNAMIC_LIST override of DYNAMIC_CORE?

[mayeut]

Suggested change

	# messing with dynamic lists and targets.
	local bitness=64
	# messing with dynamic lists.
	local bitness=64
	local target="ZARCH_GENERIC"

see https://github.com/OpenMathLib/OpenBLAS/blob/f6df9bebbb4259aa61ab5634c0f1269fb152cc0e/README.md?plain=1#L271-L273

[mayeut]

I see we are setting target="POWER8" but no explicit DYNAMIC_LIST. Should we set one?

That the other way around in this PR. One has been added but it's not supported.

Also: what happens when s390x does not actually assign a target, how does compilation work?

I honestly don't know... OpenBLAS makefiles are a bit too much too understand for me for the occasional glimpse. I proposed something based on my understanding with a link to the relevant section of the README.