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

[ocaisa]

trafficstars

A first search indicates (at least):

• CMakeMake (see issue #2420)
• ~numpy~ (no change needed to link with FlexiBLAS, cfr. https://github.com/easybuilders/easybuild-easyconfigs/pull/12935)
• SuperLU
• ~ScaLAPACK~ (fixed in ~#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 https://github.com/easybuilders/easybuild-easyconfigs/pull/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