Add support for Flexiblas

[rgommers]

Flexiblas is an interesting project, it wraps many BLAS and LAPACK libraries and appears to do so in a uniform way so that users can build against it and things "just work". It contains g77/gfortran ABI wrappers that are very similar to our own wrappers, so that should work (not tested yet). An important benefit of Flexiblas is that that then gives the ability for changing BLAS/LAPACK libraries at runtime - very useful when testing or benchmarking.

Fedora is using Flexiblas as its default library / switching mechanism, and is happy with it. This blog post illustrates the benefits: https://www.r-bloggers.com/2020/10/switch-blas-lapack-without-leaving-your-r-session/. This Fedora discussion on using Flexiblas may be useful too: https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager.

I'll note that there are multiple other ways of enabling runtime switching of BLAS/LAPACK libraries, e.g. Debian uses update-alternatives, Gentoo uses virtual/blas and virtual/lapack (see https://wiki.gentoo.org/wiki/Blas-lapack-switch), and conda-forge uses conda install "blas=*=openblas" (see https://conda-forge.org/docs/maintainer/knowledge_base.html#switching-blas-implementation). Flexiblas seems to be the most complete and well thought out one though. Everything else is more manual, e.g. conda-forge builds with our use-g77-abi command-line flag, which switches in our own ABI wrappers.

Things to consider when adding support:

1. Licensing. Flexiblas is GPLv3, with a special exception saying that the GPL does not apply if one only uses the standard (Netlib) BLAS/LAPACK interfaces to link. Should be fine, although it's a little fishy - it seems like as soon as we need a little wrapper change somewhere or a Flexiblas-specific API call, the GPL does apply again.
   • Given that we do need introspection (see (3) below) and that has to be Flexiblas-specific, this may be a showstopper.
2. ABI wrappers: are they as complete as ours? Should be apparent when running our test suite against Flexiblas-with-MKL
3. Introspection: we do need to know which BLAS library we're getting at runtime. This allows us to for example raise an exception when we see Accelerate, and report the library and version of it for debugging purposes (e.g. with scipy.show_config() or threadpoolctl).
4. threadpoolctl may need to know about Flexiblas too, because we are already using threadpoolctl for threading control in CI and in our test suite.
5. Suffixed symbols for ILP64 support - not yet implemented in Flexiblas, at least according to its website which says "Suffixed symbols for better interoperability with Julia" (SciPy uses the same as Julia at least for OpenBLAS, the 64_ suffix; MKL supports 64_ as well).

Some more discussion on Flexiblas in gh-17244 and in https://bugzilla.redhat.com/show_bug.cgi?id=1574517.

Thanks @Enchufa2 for suggesting Flexiblas. Maybe you have more thoughts on the above?

[Enchufa2]

That's a pretty good summary, I wouldn't have done better. The introspection/debugging part is a good point, because linking against -lflexiblas_api makes the GPL apply, as you said.

Pinging Martin @grisuthedragon, FlexiBLAS upstream maintainer, too.

[ogrisel]

Indeed the fact that it wouldn't be possible to update threadpoolctl to detect which FlexiBLAS backend is active without enabling the GPL is a real problem. 90%+ the libraries of the libraries of the scipy stack use permissive licenses, and in particular all the top level packages. And threadpoolctl is needed to help maintainers of those library quickly diagnose the cause of low level BLAS/OpenMP related bugs reports.

I hope that the FlexiBLAS maintainers would consider changing the licensing terms. Otherwise we will have to come up with an alternative solution of our own... but that would be a waste of effort.

[andyfaff]

I hope that the FlexiBLAS maintainers would consider changing the licensing terms. Otherwise we will have to come up with an alternative solution of our own

If not, then a third party helper package?

[grisuthedragon]

@ogrisel
As maintainer of FlexiBLAS I could think of the following options to solve the problem:
First, I can include the additional API (from flexiblas_api.h) to the linking exception. At the moment, the linking exception allows to combine FlexiBLAS with any other (even proprietary) software without violating the GPL as long as only the BLAS/LAPACK interface is used.
Second, I can think of switching to LGPL since this is less restrictive when linking/using FlexiBLAS but still remains the GPL features for FlexiBLAS itself.

If one of these two solution would help, we can discuss about a change in the FlexiBLAS licensing.

Changing the license to one from the BSD family will not be done. That's due to a personal opinion about OSS and its integration in commercial products.

[rgommers]

Thank you @grisuthedragon, that is very helpful. I think both solutions work. I'd prefer/recommend moving to LGPL though if that's possible, because:

• it makes the situation more unambiguous than GPL + custom linking exception for part of the code. E.g., there is an SPDX license expression for LGPL which tools that do dependency graph or metadata analysis can understand, while there's no such expression for a custom GPL + exception license,
• there's no risk of having to have a license discussion again if there's another part of FlexiBLAS that may be needed but doesn't fall under the exception (perhaps it gets added in the future),

Changing the license to one from the BSD family will not be done. That's due to a personal opinion about OSS and its integration in commercial products.

That's perfectly fine and understandable. We don't need BSD/MIT, LGPL is nice too. We also ship other LGPL (and the GCC runtime with its linking exception) as part of our binaries.

[jeremiedbb]

4. threadpoolctl may need to know about Flexiblas too, because we are already using threadpoolctl for threading control in CI and in our test suite.

Hi, just to let you know that the support of FlexiBLAS in threadpoolctl is ready: joblib/threadpoolctl#156. The only blocker for inclusion is the license consideration since we do need to access the flexiblas specific API.

[rgommers]

That looks great, thanks for working on this @jeremiedbb!

[grisuthedragon]

So I release FlexiBLAS 3.4.0 which is now licensed under LGPL.

[rgommers]

Awesome, thank you @grisuthedragon!

[rgommers]

We now have a guide that includes use of FlexiBLAS with SciPy (= actually a nice way to work on debugging linalg issues): http://scipy.github.io/devdocs/dev/contributor/debugging_linalg_issues.html#debugging-linalg-issues

The threadpoolctl support is available too, so I think we can declare victory here.

Thanks all!