Facilitate the choice of BLAS provider (specifically MKL) at runtime

As conda-forge successfully demonstrated, it is possible to compile numpy and scipy against the netlib reference implementation of BLAS and LAPACK, and then switch to OpenBLAS, MKL, or BLIS at runtime.

To be able to switch to MKL without some functions segfaulting (#3193), one of the following should be done:

1. build scipy with SCIPY_USE_G77_ABI_WRAPPER=1 (introduced in #10591 for conda-forge by @isuruf),
2. have MKL_INTERFACE_LAYER=LP64,GNU in the environment at runtime (introduced by Intel to fix #3193) (also done in conda-forge, just in case?).

To facilitate the work of distributors, it would make sense for the default build options to be maximally compatible. From #10591, “this wrapper works for all cases and incurs only a tiny overhead”, which seems like a good tradeoff. Is there any other reason not to always use those wrappers? Or at least make it the default?

[pv]

I think the wrappers would be more cleanly implemented as a separate ABI-compatibility wrapper library, which would provide compatible symbols. The hurdle here is mainly distutils and getting the linker flags etc. right on all platforms to do the symbol overriding correctly. (For distributors, the distutils issue does not exist and there’s better control over compilers etc. to get it right vs. platforms.)

This would allow us to stop patching sources, make it easier to provide 100% coverage of the relevant blas/lapack API instead of piecemeal, and avoid mistakes and the maintenance annoyance with the patching.

For Accelerate I remember seeing such existing (3rd-party) blas/lapack wrapper libraries — maybe they exist also for MKL on OSX?

[pv]

The default build options correspond to BLAS that is ABI-compatible with the Fortran compiler used.

The Fortran ABI is something that the binary distributor has to coordinate across all packages, and using ABI-incompatible compiler/library combo requires some sort of hack in all Fortran programs, so Scipy is not special. Most environments (Linux distributions, HPC environments, etc.) install libraries that are compatible with the Fortran compilers they are providing.

The MKL(g77)+gfortran combination in conda/conda-forge is a strange outlier with the ABI-incompatibility. AFAIK, MKL has also gfortran ABI-compatible libraries, but I’m not familiar with conda-forge so I don’t know the reason why those are not used.

The wrappers are an ugly hack (incl. patching of vendored Fortran sources) that try to paper over ABI differences. Part of them uses cblas and is Fortran ABI-independent, but not everything is available in cblas, and is instead implemented by just correcting for the differences in the calling convention. E.g. the following Cython module:

from scipy.linalg.cython_lapack cimport cladiv
cdef float complex a = 1, b = 1
print("This should print (1+0j):")
print(cladiv(&a, &b))

prints garbage with wrong wrappers vs. ABI — under conda-forge this works only for MKL with MKL_INTERFACE_LAYER env var unset (i.e. the case the wrappers are intended to work in). Arpack no longer uses such functions in versions several years ago, so the impact from these wrong results due to incompatible LAPACK is currently probably not critical in practice.