Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upENH: build also openblas64_ 64-bit symbol-suffixed library #8
Conversation
Build OpenBLAS with 64-bit integer size and symbol suffix '64_' (INTERFACE64=1 SYMBOLSUFFIX=64_). This is 64-bit BLAS/LAPACK convention avoiding symbol clashes with 32-bit BLAS/LAPACK, originally introduced for Julia. OpenBLAS built with this setting is also provided by some Linux distributions (e.g. Fedora's 64-bit openblas packages).
Store only the source.zip file.
…s also on failure
|
I read over the changes---seems ok to me & CI is green. I can lift the Draft Status and merge, but will wait for your "ok" first. The binaries won't get uploaded until this is merged since the secret tokens won't work from your fork of the repo. It seems to me that this is unlikely to break the workflow for the current OpenBLAS binaries & will give us some new 64 bit integer ones we can start downloading for testing (and some day for 64-bit wheels, when ready). |
|
Yes, I believe this won't change the way the 32-bit OpenBLAS libs are built, and should be OK to merge. The 64-bit Windows and Linux binaries produced I think are fine. The 64-bit OSX binaries I can't check locally, apart from just the symbol names, but they're here if you want to check before merging: https://github.com/pv/openblas-libs/tree/files-osx-x86_64-1 Anyway, getting this merged would be a big help, as it would allow setting up CIs for the 64-bit BLAS (at least for the symbol-suffixed configuration). Otherwise, I think bitrot will eventually set in when someone forgots to use the |
|
Any reason not to merge this? |
|
I was going to spot-check that generated binary locally first by running full NumPy suite with it on MacOS. |
|
I've confirmed the NumPy 64-bit test passes with the MacOS OpenBLAS binary produced here:
Full test suite also looks good with same OpenBLAS:
Note that I had to do two things to make this work, both of which are par for the course on Mac with our toolchain:
So, merging, thanks for your patience. |
|
Thanks! This is really nice work all around |
|
Would it also be possible to push the OpenBLAS v0.3.7 builds (which is the version numpy CI is currently using)? I guess this involves pushing a commit to master. |
|
Let me check if I have sufficient permissions to push a feature branch to the repo & then open a PR from that---I believe that would allow the upload to occur if I understood @matthew-brett correctly a few months ago. |
Build OpenBLAS with 64-bit integer size and symbol suffix '64_' (INTERFACE64=1
SYMBOLSUFFIX=64_).
This is 64-bit BLAS/LAPACK convention avoiding symbol clashes with
32-bit BLAS/LAPACK, originally introduced for Julia. OpenBLAS built
with this setting is also provided by some Linux distributions (e.g.
Fedora's 64-bit openblas packages).
And for clarification: the objconv tool is necessary only for OSX,
where OpenBLAS Makefiles use it for symbol renaming. As noted
in the commits, the sources are from https://www.agner.org/optimize/#objconv
and I checked the diffs vs. a few other places that are distributing
that tool.
c.f. numpy/numpy#15012