Including FlexiBLAS as the default BLAS in foss will require easyblock changes

[ocaisa]

A first search indicates (at least):

• CMakeMake (see issue Should set BLA_VENDOR in CMakeMake easyblock if BLAS is in the toolchain #2420)
• numpy (no change needed to link with FlexiBLAS, cfr. {lang}[foss/2021.04] SciPy-bundle v2021.05 easybuild-easyconfigs#12935)
• SuperLU
• ScaLAPACK (fixed in make ScaLAPACK easyblock aware of FlexiBLAS #2427)
• LAPACK
• MXNet
• AMBER
• GAMESS-US
• WIEN2k

[ocaisa]

I think the numpy one in particular needs to be tackled before we merge the SciPy bundle for 2021a

[boegel]

As discussed in today's EB conf call: we should also come up with a way to detect unintentional direct linking to libraries like OpenBLAS, probably by enhancing the sanity check in framework, perhaps specifically for toolchains that include FlexiBLAS as a component?
We can definitely leverage some of the existing stuff that is used for the RPATH sanity check...

[boegel]

@ocaisa The numpy easyblock doesn't need any changes at all to link correctly with FlexiBLAS, verified with easybuilders/easybuild-easyconfigs#12935 .

[branfosj]

Building R (4.1.0) in 2021a I get:

WARNING: R will be built with generic BLAS, which will result in poor performance.

So, flexiblas is not being detected / used.

[branfosj]

Building R (4.1.0) in 2021a I get:

WARNING: R will be built with generic BLAS, which will result in poor performance.

So, flexiblas is not being detected / used.

The R configure script has a library flag (-lopenblas, etc.) to BLAS library name translation section. This does not know about FlexiBLAS and the default is to identify it as a generic BLAS library. The R easyblock picks this up as an issue and warns us.

[boegel]

@ocaisa Should we still keep this open?

[ocaisa]

Well, since we check for linking to openblas now, I think this can be closed. The issue will present it self when a pr is made for the relevant easyblocks