Conversation
|
Thanks Matti. Some non-existing |
|
Right, it is a shame to burn so much CI. I can reproduce the failures locally. After the build starts to work, I am seeing This should be |
That wouldn't be surprising, since we've never used a prefix for anything. I'm fairly sure that it'll be missing in more places. I think this is going to intersect substantially with the re-introduction of ILP64 support, which is ongoing in other branches. So we should probably pause this until ILP64 support is back. |
|
OK |
* Related to scipygh-16930 * added a regression test, based on the reproducer in the issue, that I confirmed does indeed fail locally on x86_64 Linux via: `CIBW_BUILD=cp311-* cibuildwheel --platform linux --archs x86_64` * this assumes that scipygh-20074 needs a little more time because of all the moving parts related to that * I spent a few hours on this today, and unfortunately I don't see an obvious fix because the "newest of the old" OpenBLAS binaries we were using at https://anaconda.org/multibuild-wheels-staging/openblas-libs/files are too old to fix the test via `cibuildwheel` in my hands; conversely, the new OpenBLAS binaries (https://anaconda.org/scientific-python-nightly-wheels/openblas-libs/files) don't seem to offer a version that is simultaneously new enough while not introducing at least a subset of the challenges experienced by scipygh-20074 (yikes!) [skip cirrus] [skip circle]
* Related to scipygh-16930 * added a regression test, based on the reproducer in the issue, that I confirmed does indeed fail locally on x86_64 Linux via: `CIBW_BUILD=cp311-* cibuildwheel --platform linux --archs x86_64` * this assumes that scipygh-20074 needs a little more time because of all the moving parts related to that * I spent a few hours on this today, and unfortunately I don't see an obvious fix because the "newest of the old" OpenBLAS binaries we were using at https://anaconda.org/multibuild-wheels-staging/openblas-libs/files are too old to fix the test via `cibuildwheel` in my hands; conversely, the new OpenBLAS binaries (https://anaconda.org/scientific-python-nightly-wheels/openblas-libs/files) don't seem to offer a version that is simultaneously new enough while not introducing at least a subset of the challenges experienced by scipygh-20074 (yikes!) [skip cirrus] [skip circle]
* Related to gh-16930, but doesn't fix it just yet, just updates to OpenBLAS `0.3.26` and adds an xfailed regression test (the test doesn't yet pass on all platforms after the OpenBLAS version bump) * the xfailed regression test, based on the reproducer in the issue, does indeed fail locally on x86_64 Linux before the patch (OpenBLAS version bump) and pass after via: `CIBW_BUILD=cp311-* cibuildwheel --platform linux --archs x86_64` * this assumes that gh-20074 needs a little more time because of all the moving parts related to that * use manylinux2014 for linux-32 bit openblas --------- Co-authored-by: mattip <matti.picus@gmail.com>
openblas_support.py
I am not sure which branches/PRs are relevant. Certainly #20510, are there others? |
|
The key one was gh-19816 (and other PRs split off from that. They're all merged now, so this PR is unblocked I believe. There are a lot of conflicts here, and I think it's a little tricky to figure out what is relevant and what is not. It may be better to open a new PR, using an |
|
Replaced by #20585 |
Builds on numpy/numpy#25505 to refactor wheel building
tools/openblas_support, use wheels insteadv0.3.20-571(in the openblas_support script) andv0.3.23.293(in the ci test runs) to v0.3.26, and add a single source of truth in arequirements/openblas_requirements.txtfilecc@ matthewfeickert