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.