BUG: Meson build creates broken scipy.sparse.linalg._isolve on archlinux w/ system openblas

[mkoeppe]

Describe your issue.

see https://trac.sagemath.org/ticket/34779

Reproducing Code Example

https://github.com/sagemath/sage/blob/develop/build/pkgs/scipy/spkg-install.in

Error message

{{{
 [sagemath_doc_html-none]   [plotting ]   File "/sage/local/var/lib/sage/venv-python3.10/lib/python3.10/site-packages/scipy/sparse/linalg/_isolve/iterative.py", line 9, in <module>
  [sagemath_doc_html-none]   [plotting ]     from . import _iterative
  [sagemath_doc_html-none]   [plotting ] ImportError: /sage/local/var/lib/sage/venv-python3.10/lib/python3.10/site-packages/scipy/sparse/linalg/_isolve/_iterative.cpython-310-x86_64-linux-gnu.so: undefined symbol: slamch_
}}}

SciPy/NumPy/Python version information

1.9.3

[rgommers]

Thanks for the report @mkoeppe. That is a very annoying compatibility issue in the way Arch Linux builds OpenBLAS. From https://trac.sagemath.org/ticket/34081#comment:61: "I suppose this is caused by our openblas not including lapack symbols. Our distro package is fine since we haven't switched to meson (yet)".

From the OpenBLAS README: For a general introduction to the BLAS routines, please refer to the extensive documentation of their reference implementation hosted at netlib: https://www.netlib.org/blas. On that site you will likewise find documentation for the reference implementation of the higher-level library LAPACK - the Linear Algebra Package that comes included with OpenBLAS.

Arch Linux builds OpenBLAS with the non-default NO_LAPACK=1: https://github.com/archlinux/svntogit-community/blob/54dec2e1cd8b576e749038c8028b8b66b3c94f2f/trunk/PKGBUILD#L23. That seems like a very unhealthy choice. Also because OpenBLAS doesn't just include a copy of Netlib LAPACK, it replaces routines with more optimized ReLAPACK implementations.

As reported on the Sage issue, it can be worked around by using meson setup .... -Dlapack=lapack to builds against the reference LAPACK instead.

The reason this doesn't show up in the setup.py based builds is that the numpy.distutils BLAS/LAPACK detection does symbol checks (only for OpenBLAS, probably because of this issue) and skips a detected library if it's present but misses those symbols. See _require_symbols in numpy/distutils/system_info.py.

I guess I'll put this on the pile of BLAS/LAPACK detection work. There is a design issue here - if we're asking Meson for dependency('openblas') it caches the result of there. So if we make that call twice, once for blas and once for lapack, we by design get the same result. And what we want here is to get YES for blas and NO for lapack. So that'll require some change in API.

@antonio-rojas any chance this can be changed in Arch Linux? Even once we improve handling this in SciPy, it will continue to be a footgun when explicitly selecting libraries with dependency('openblas'), and it loses performance.

[antonio-rojas]

@antonio-rojas any chance this can be changed in Arch Linux? Even once we improve handling this in SciPy, it will continue to be a footgun when explicitly selecting libraries with dependency('openblas'), and it loses performance.

I'd very much like that, since this is not the first time our non-standard openblas packaging is causing issues with other projects, but this is ultimately the package maintainer's decision @felixonmars

We would still keep building our official scipy package against netlib's blas though, as we don't want to tie the package to any specific blas implementation.

[rgommers]

We would still keep building our official scipy package against netlib's blas though, as we don't want to tie the package to any specific blas implementation.

That's not an issue - it looks like libblas.so is a symlink, so if one installs openblas one still gets scipy + openblas. This kind of "virtual BLAS package" is what many distros do, to ensure that all packages pick up the same library and that that library is runtime switchable.