Build LAPACK

[ViralBShah]

Now that we have LBT, we have situations where some libraries provide both BLAS and LAPACK (OpenBLAS, MKL) and we can have situations where we only have a BLAS provider (Accelerate, BLIS, AmdBLIS). For situations, where we only have a BLAS provider, we should build the reference LAPACK and provide it through Yggdrasil.

cc @staticfloat

[ViralBShah]

Also worth looking at: https://github.com/HPAC/ReLAPACK

[DilumAluthge]

@ViralBShah can this be closed now that #2658 is merged?

[ViralBShah]

We need to update the LAPACK build to have 64_ suffixes for ILP64 platforms and also call our ilp64_ BLAS. Leaving this open for now.

[ViralBShah]

@giordano What would be the easiest way to add 64_ suffixes for ILP64 platforms in LAPACK_jll? We need to ship it separately in cases where we have a vendor BLAS but not a good vendor LAPACK - like Accelerate.

It would be nice to have M1 switch over to Accelerate.

[giordano]

I guess remapping the symbols with macros?

[ViralBShah]

Anything in the LBT infrastructure I can reuse for that? While compiling fortran files, I can always do -Ddpotrf=dpotrf_64 and construct a huge list of command line flags. Is there a better way to do it, like pass in a header file during compilation of individual .f files?

[giordano]

Strictly speaking, the fortran standard doesn't require preprocessor directives like #define, although some compilers do allow them (I know gfortran does that, I presume most common would do the same). I'm away from computer right now, I can't check whether #include directives would work. You can always use fortran's own include statement.

[ViralBShah]

I was trying to think about ways of doing this without having to edit the fortran files.

[giordano]

Then redefining the symbols on the command line with -D is your best bet. We haven't it yet, but we should provide a utility to generate the list of -D arguments to remap all BLAS symbols, we already do this in many places and it's cumbersome to do it manually