Repository navigation
MAINT: update scipy-openblas to 0.3.34.237.2 - #26447
Conversation
github-actions
Bot
added
the
maintenance
|
It seems I submitted this too early, the uv lock update requires that the package be 7 days old and I released scipy-openblas only two days ago. Revisit this in a week. |
| ] | ||
| openblas64 = [ | ||
| "scipy-openblas64==0.3.34.237.0", | ||
| "scipy-openblas64==0.3.34.237.2", |
There was a problem hiding this comment.
Do you recommend that I also "backport" this bump for SciPy 1.18.2? Currently, in gh-26199, we're proposing to bump from 0.3.31.22.0 -> 0.3.34.237.0, which I thought included the important patches.
We can't actually backport this PR, because the release branch maintains OpenBLAS version pins the "old way," but I'm just asking if 0.3.34.237.2 makes sense there as well, instead of 0.3.34.237.0.
There was a problem hiding this comment.
I think so, since .0 -> .2 adds a bug fix and shrinks the wheel size
|
It's more than 7 days now, do you want to open the SciPy-release PR @mattip ? |
Running |
|
This needs to be merged first, because scipy-release goes off this repo's pyproject.toml. |
|
Test fail is unrelated. |
Reference issue
numpy/numpy#27989: threading issue in OpenBLAS on windows with large machines
What does this implement/fix?
Update the version of scipy-openblas to latest. This picks up the fix for windows, and also an additional change to scipy-openblas on posix platforms. The library now statically links to only use parts of
libgfortran.a, which both shrinks the library and removes the dependence on the problematiclibquadmath.sowhich is licensed with LGPL3. Note that libgfortran.so that ships with manylinux2_39 already drops that dependency, but we are still building with manylinux2_28.Additional information
This will break scipyscipy-release until the dependency is matched there. The PR to fix that should drop the libquadmath license file and note that libgfortran is now statically linked, like numpy/numpy-release#70
AI Generation Disclosure
None used