update OpenBLAS commit, use macos-15.intel

[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)

Towards #219.

• Use macos-15-intel. As found in cibuildwheel for windows and travis #221 and use macos-15 images #216, this causes test failures.
• Update to latest OpenBLAS head commit 585e6d06802a which is v0.3.30-317. This means we can remove the patch since it was incorporated upstream.
• Remove some leftover cruft from the move away from multibuild

[rgommers]

Wow, that's a sizeable log. Adding -Wno-shift-op-parentheses -Wno-logical-op-parentheses -Wno-deprecated-declarations may be useful.

The relevant problem seems to be:

... <lots of these "has no symbols" warnings> ...
/Applications/Xcode_16.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../libscipy_openblas64_.a(droundup_lwork.o) has no symbols
/Applications/Xcode_16.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../libscipy_openblas64_.a(la_xisnan.o) has no symbols
No receipt for 'com.apple.pkg.Xcode' found at '/'.
make[1]: warning: -jN forced in submake: disabling jobserver mode.

Input library: ../libscipy_openblas64_.a, Format: Mach-O Little Endian64, Output: ../libscipy_openblas64_.a.osx.renamed, Format: Mach-O Little Endian64

Symbol names changed
ld: warning: reducing alignment of section __TEXT,__text from 0x10000 to 0x1000 because it exceeds segment maximum alignment
Applications/Xcode_16.app/Contents/Developer/usr/bin/make -s -C utest all
No receipt for 'com.apple.pkg.Xcode' found at '/'.
make[1]: warning: -jN forced in submake: disabling jobserver mode.
d: warning: ignoring duplicate libraries: '-lpthread'
ld: warning: reducing alignment of section __TEXT,__text from 0x10000 to 0x1000 because it exceeds segment maximum alignment
test_extensions/xerbla.c:56:85: warning: format specifies type 'int' but the argument has type 'blasint' (aka 'long') [-Wformat]
   56 |       printf("***** XERBLA WAS CALLED WITH INFO = %d INSTEAD OF %d in %s *******\n",info, _info, srname);
      |                                                   ~~                                ^~~~
      |                                                   %ld
1 warning generated.
ld: warning: ignoring duplicate libraries: '-lpthread'
ld: warning: reducing alignment of section __TEXT,__text from 0x10000 to 0x1000 because it exceeds segment maximum alignment
TEST 1/125 min:smin_negative make[1]: *** [run_test] Bus error: 10
make: *** [tests] Error 2
##[endgroup]
                                                           �[31m✕ �[0m3040.63s
##[error]cibuildwheel: Command bash ci-before-build.sh failed with code 2. 

No idea what is going on there. Perhaps the XCode version bump matters? Might be pragmatic to see if the pre-cibuildwheel-conversion code has the same issue when run on macos-15-intel.

[mattip]

Might be pragmatic to see if the pre-cibuildwheel-conversion code has the same issue when run on macos-15-intel

Yes it did. See #216

[ffgan]

Might be pragmatic to see if the pre-cibuildwheel-conversion code has the same issue when run on macos-15-intel

Yes it did. See #216

I think if possible, this issue may need assistance from the @ openblas maintainers to investigate. I've tried using the patch here as well as compiling with the commits included in that PR, but I'm still getting the same error.

[ffgan]

If needed, I can create a separate repository that uses GitHub Actions to reproduce this bug and simplify the current workflow, so that the OpenBLAS team can investigate it more easily.

[mattip]

I commented on the upstream issue around smin_negative at OpenMathLib/OpenBLAS#5477

[mattip]

Digging back through history, the pre-#211 code used a github action to set xcode==15.4, and once the image updated that action started to fail. I found a successful x86_64 build from August 17.

[mattip]

It seems the gfortran in the macos images is not really what we need, see the discussion on #224. Even if I could get it to actually work, it would not build for the older versions of macos we wish to target. Over in cibuildwheel, there is an open question of how to do this pypa/cibuildwheel#2610

[mattip]

I think we should reverse course in windows and macos. We should not use cibuildwheel there, the containerization in cibuildwheel only obfuscates the scripts. We should set up a build environment, probably the easiest is with conda compilers, and then call build-openblas.sh. This means we will need to bump the x86_64 MACOSX_DEPLOYMENT_TARGET from 10.9 to 10.13 (since that is what is supported in the conda compilers), but I think that is the least bad option.

I think it would simplify upstream compatibility if we use CMake in build-openblas.sh, but that is a separate issue.

[ffgan]

I think we should reverse course in windows and macos. We should not use cibuildwheel there, the containerization in cibuildwheel only obfuscates the scripts. We should set up a build environment, probably the easiest is with conda compilers, and then call build-openblas.sh. This means we will need to bump the x86_64 MACOSX_DEPLOYMENT_TARGET from 10.9 to 10.13 (since that is what is supported in the conda compilers), but I think that is the least bad option.

I think it would simplify upstream compatibility if we use CMake in build-openblas.sh, but that is a separate issue.

Perhaps we could open these two issues. If possible, could you please assign the CMake one to me? I'll try to add support for it in a few days.

[mattip]

• arm64 manylinux is failing tests with SBGEMM FAILURES: 28800, arm64 musllinux is passing. Strange. This is on OpenBLAS commit 585e6d06802a0 which is the current develop HEAD
• macos-x86_64 is still failing with TEST 1/125 min:smin_negative make[1]: *** [run_test] Bus error: 10, using xcode 16 and gfortran GNU Fortran (GCC) 11.3.0.
• macos-arm64 fails to build. There are problems with fortran linking. This is something new since commit 7cbbb0f.

This whole PR is in worse shape than #220, which was passing CI. Maybe I should start again.

[mattip]

Closing in favor of #225