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