Matthieu Darbois

might be worth looking at Jenkins logs but all seem good from the status check point of view.

This can be tested on armv7l, c.f. numpy test https://github.com/pypa/auditwheel/blob/4d3c2d5ebc6ccf9468b09337e0e206575b59b7c9/tests/integration/test_manylinux.py#L422-L428

It was announced in https://github.blog/changelog/2024-06-03-actions-arm-based-linux-and-windows-runners-are-now-in-public-beta/ that the expectation was that it would be available before the end of the year for OSS project: > Arm runners are available to customers...

If going this way, would it be worth to also include symbol prefix/suffix with such a macro ? e.g. something like ``` #define OPENBLAS_API(return_type, base_name, args) OPENBLAS_EXPORT return_type prefix##base_name##suffix args...

> Is ZLIB_NG_2.1.0 mistaken for ZLIB_* or is that intended? it's not intended, needs a fix to exclude `ZLIB_NG_*`. > Is there a workaround? The only one I can think...

gcc-toolset-15 is available in RedHat only while waiting for new point releases of AlmaLinux/RockyLinux. This will probably happen around the end of the month.

I'm not sure why riscv64 passes the `RunCMake.execute_process` test given the output of the failure on s390x/ppc64le. Either QEMU does not behave the same or there's something in the CMake...

> I'm not sure why riscv64 passes the RunCMake.execute_process test given the output of the failure on s390x/ppc64le. QEMU does not behave the same on core dump signals

since popping the PYTHONPATH environment variable seemed to work, I tried to modify the shebang to use `-E` and in order to simplify the script a bit (not sure it...