BLD: start using scipy_openblas wheels in cibuildwheel

[andyfaff]

No description provided.

[andyfaff]

@rgommers, I've been testing out the scipy_openblas wheel in cibuildwheel locally.

I can get the wheel to build, but the tests fail because the repaired wheel does not contain the openblas .so within scipy.libs.
What's weird is that when I run ldd on an .so that uses BLAS symbols, there is no BLAS .so listed:

[root@ab93aa8fbfa0 linalg]# ldd /opt/_internal/cpython-3.10.7/lib/python3.10/site-packages/scipy/linalg/_fblas.cpython-310-aarch64-linux-gnu.so
	linux-vdso.so.1 =>  (0x0000ffffa60c1000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000ffffa5fbd000)
	libc.so.6 => /lib64/libc.so.6 (0x0000ffffa5e37000)
	/lib/ld-linux-aarch64.so.1 (0x0000ffffa6093000)

Using nm -C -u I see that all the BLAS symbols are both unmangled and undefined.

If I install scipy_openblas32 then the tests run.

What's the way forward here? Somehow the repair process has to pull in the openblas library to include in scipy.libs, and mangle all the symbols in the openblas library as well as the undefined symbols in the scipy .so.

I appreciate this is at the cutting edge of what is being done with the openblas wheel, sorry if I'm jumping the gun, it's probably what you're alluding to in scipy#19381 (comment).

[andyfaff]

The openblas.pc produced by scipy_openblas.get_pkg_config() is different to that distributed with non-wheel form. Does the lack of entries in Libs (or the defined entries in Libs.private) cause all the scipy .so to not know how to resolve missing BLAS symbols?

>>> print(op.get_pkg_config())
libdir=/opt/_internal/cpython-3.10.7/lib/python3.10/site-packages/scipy_openblas32/lib
includedir=/opt/_internal/cpython-3.10.7/lib/python3.10/site-packages/scipy_openblas32/include
openblas_config= OpenBLAS 0.3.23.dev DYNAMIC_ARCH NO_AFFINITY armv8 MAX_THREADS=64
version=0.3.23.dev
extralib=-lm -lpthread -lgfortran -lquadmath -L${libdir} -lopenblas_python
Name: openblas
Description: OpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 BSD version
Version: ${version}
URL: https://github.com/xianyi/OpenBLAS
Libs: 
Libs.private: ${extralib}
Cflags: -I${includedir} 

(dev3) 192-168-1-107:pkgconfig andrew$ cat openblas.pc 
libdir=/opt/arm64-builds/lib
libsuffix=
includedir=/opt/arm64-builds/include
openblas_config= USE_64BITINT= DYNAMIC_ARCH=1 DYNAMIC_OLDER= NO_CBLAS= NO_LAPACK= NO_LAPACKE= NO_AFFINITY=1 USE_OPENMP= SANDYBRIDGE MAX_THREADS=3
version=0.3.21.dev
extralib=-lpthread -lgfortran -lpthread -lgfortran
Name: openblas
Description: OpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 BSD version
Version: ${version}
URL: https://github.com/xianyi/OpenBLAS
Libs: -L${libdir} -lopenblas${libsuffix}
Libs.private: ${extralib}
Cflags: -I${includedir}

[rgommers]

I appreciate this is at the cutting edge of what is being done with the openblas wheel, sorry if I'm jumping the gun, it's probably what you're alluding to in scipy#19381 (comment).

Not at all, thanks for working on this! And yes, it's this comment:

Getting rid of tools/openblas_support.py would be great. This can be done, I think it only needs the ability in scipy_openblas32 to write out a pkg-config file that doesn't do the libopenblas_python thing but contains the normal link flags. Then it's a 1:1 replacement, and we can simply use pip instead of the hardcoded logic for downloading the right binary in openblas_support.py without changing anything else to how we build wheels.

The openblas.so in the wheel is more or less the same as in the older tarball, so we should be linking it the same way. Hence what we need is a regular openblas.pc, rather than the custom scipy-openblas.pc which allows building does not create a NEEDED entry for the shared library in the extension modules that link against BLAS/LAPACK.

The scipy_openblas packages don't yet have a function to write out that regular openblas.pc. I think it needs a second function like https://github.com/MacPython/openblas-libs/blob/main/local/scipy_openblas64/__init__.py#L54.

There is one difference though in shared libraries, beyond the name being different - it was already repaired by auditwheel. I think this shouldn't matter, all it should be doing is adding .protected to the symbol visibility. However, if we add a symbol prefix as I suggested in scipy#19381, that's no longer true - and we should adapt to that in the npy_cblas.h header we ship. So we should sort that out first I think, before starting to use the openblas wheels in the scipy wheel build process.