cc @mattip

I think you can use the v0.3.26 tarballs from https://anaconda.org/scientific-python-nightly-wheels/openblas-libs, so you would need to modify tools/openblas_support.py:

- OPENBLAS_V = '0.3.21.dev'
- OPENBLAS_LONG = 'v0.3.20-571-g3dec11c6'
+ OPENBLAS_V = '0.3.26'
+ OPENBLAS_LONG = 'v0.3.26'

I tried that, but it turns into scipy-openblas32 land problems instead of the usual old approach:

  Run-time dependency scipy-openblas found: YES 0.3.26

  ../scipy/meson.build:242:4: ERROR: File _distributor_init_local.py does not exist.

I'd probably have to start making shims to adjust this branch to match your new infrastructure, no?

Sorry. I must have overwritten it at some point. It seems the previous one was

- OPENBLAS_V = '0.3.21.dev'
- OPENBLAS_LONG = 'v0.3.20-571-g3dec11c6'
+ OPENBLAS_V = '0.3.24-dev'
+ OPENBLAS_LONG = 'v0.3.24-95-g9d425a5f'

That fails too--I'm pretty sure I tried most of the binaries up there yesterday. I'll paste the error I got yesterday for that scenario below:

  [241/1494] Linking target scipy/special/_ellip_harm_2.cpython-311-x86_64-linux-gnu.so
  FAILED: scipy/special/_ellip_harm_2.cpython-311-x86_64-linux-gnu.so
  cc  -o scipy/special/_ellip_harm_2.cpython-311-x86_64-linux-gnu.so scipy/special/_ellip_harm_2.cpython-311-x86_64-linux-gnu.so.p/meson-generated__ellip_harm_2.c.o scipy/special/_ellip_harm_2.cpython-311-x86_64-linux-gnu.so.p/sf_error.c.o -Wl,--as-needed -Wl,--allow-shlib-undefined -Wl,-O1 -shared -fPIC -Wl,--start-group -lm -Wl,--version-script=/project/scipy/_build_utils/link-version-pyinit.map -L/usr/local/lib -lopenblas -Wl,--end-group
  /opt/rh/devtoolset-10/root/usr/libexec/gcc/x86_64-redhat-linux/10/ld: cannot find -lopenblas
  collect2: error: ld returned 1 exit status

Ok I will make sure there is a 0.3.26 you can use. It might take me a day or so.

Which platforms do you need openblas tarballs for? Do you ship linux aarch64? That builds on travis which is flaky and not cooperating (this is a known problem with travis CI, would be nice to find a different aarch64 CI system but that is another problem).

Cirrusci can handle Linux aarch64 relatively straightforwardly

It seems #20228 is working, using the 0.3.26 tarballs I uploaded today to https://anaconda.org/multibuild-wheels-staging/openblas-libs/files

@mattip Awesome, thanks a lot!

I confirmed locally that with your commits pulled in from the cross-linked PR combined with your work to provide a new OpenBLAS build upstream, this branch passes the regression test to fix the issue in question.

I'm going to proceed with a full wheel build with your two commits cherry-picked in here now, and if there are no related failures we can move forward I think.

@andyfaff is there a way for me to manually override the Cirrus Linux ARM wheel build skips on a PR/feature branch like this? (without changing the source code--I'm pretty sure my manual re-run trigger just skipped again and uploaded some previous artifact)

Do I understand you want the cirrus runs to be forced to go again? If so, I've just forced them to run again.

So close! A single failure on the macOS x86-64 jobs:

  ../venv-test/lib/python3.10/site-packages/scipy/linalg/tests/test_blas.py:1102: in test_gh_169309
      assert_allclose(actual, expected)
          actual     = 0.0
          expected   = 22.360679774997898
          x          = array([10, 10, 10, 10, 10, 10, 10, 10, 10])
  /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/contextlib.py:79: in inner
      return func(*args, **kwds)
  E   AssertionError: 
  E   Not equal to tolerance rtol=1e-07, atol=0
  E   
  E   Mismatched elements: 1 / 1 (100%)
  E   Max absolute difference among violations: 22.36067977
  E   Max relative difference among violations: 1.
  E    ACTUAL: array(0.)
  E    DESIRED: array(22.36068)

So perhaps not fully fixed upstream. Perhaps drop the added test from this PR, and @ev-br may want to investigate further? Getting OpenBLAS 0.3.26 shipped in the next release will be quite nice either way.

Sure, feel free to skip it, I'll take a look. dnrm2 sounds familiar.

Looks like the wheels failed the new test on a few different platforms even with OpenBLAS 0.3.26. I've pushed in a commit to xfail (and run=False) the new test for now, with reference to the issue that should remain open for now.

Once the regular CI is happy, perhaps we should squash-merge.

I believe the remaining CI failures are gh-20230.

I squash-merged--I'd like to see a few days of the new OpenBLAS getting flushed through before branching for 1.13.0 around Sunday (I think).