Support Lapack natively

[certik]

This is in some sense similar to #354. fpm should have a first class support for Lapack and its fast implementations. Many times you have to enable MKL in Intel with special options based on the Intel compiler version, and so on.

I don't know exactly what we need to do technically, whether we can design a general mechanism in our package management, or simply hardwire Lapack like we will hardwire MPI.

[awvwgk]

See #330 for a related discussion.

[ivan-pi]

I'd be interested to come-up with some ideas for better LAPACK and BLAS support in fpm.

Here are a few issues I'm currently running into:

• Conflicting library/compiler versions; this manifests after installing LAPACK and BLAS with sudo apt-get install libblas-dev liblapack-dev, and separately a newer version of gfortran. Upon linking I get warnings such as:

  /usr/bin/ld: warning: libgfortran.so.4, needed by /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/liblapack.so, may  conflict with libgfortran.so.5
  

  The recommended solution is to compile LAPACK from scratch with the targeted compiler. Here are a few links with the same issue: link1, link2, link3, link4

• Conflicting libraries; the quickstart-fortran installer for Windows from @LKedward ships with OpenBLAS that also includes LAPACK. On Windows I would like to use link = ['openblas'] in the manifest, but on Linux I'm using link = ['lapack', 'blas'] in the manifest. This is hindering cross-platform portability.

• Wrong linking order; since the linker satisfies dependencies from left to right, one ought to write -llapack -lblas and not -lblas -llapack. (Does every program that uses LAPACK also require BLAS?)

Some thoughts on native support:

• Automatic detection of LAPACK or BLAS calls is tricky, as it would require parsing source code.
• A hacky solution would be to analyze linker output, and check for undefined references such as these:

dvode_lapack.f:(.text+0x24c): undefined reference to `dgetrs_'
dvode_lapack.f:(.text+0x606): undefined reference to `dgetrf_'

• A mock-package approach (see comment) might be one way. In case of multiple libraries, a priority mechanism like in update-alternatives could be established.
• We could try to search for installed LAPACK libraries, similar to the compiler toolchains. The FindLAPACK.cmake in lapack-cmake-meson from @scivision can serve as reference.
• Combining LAPACK and BLAS from different vendors is probably a bad idea so it should be forbidden (an exception is the reference LAPACK, which can be linked with any BLAS library).

---

Here's an attempt at a list of available BLAS and LAPACK libraries if someone would like to study their differences.

Common BLAS libraries:

• Netlib BLAS - Reference version
• ATLAS - Automatically Tuned Linear Algebra Software
• GotoBLAS - BLAS implementation of Kazushige Goto, discontinued
• OpenBLAS - open source fork of GotoBLAS
• Intel MKL BLAS - optimized version of BLAS for Intel Pentium, Core, and Intel Xeon CPU's and Xeon Phi

Using BLAS in C/C++ programs:

• CBLAS - C interface to Fortran BLAS
• GSL BLAS - GSL version of BLAS (operates on vector and matrix structs)
• uBLAS - C++ template library with BLAS functionality, part of Boost C++ libraries
• blaspp - C++ API for BLAS
• BLIS - BLAS-like Library Instantiation Software built upon ideas of GotoBLAS; also the basis for AMD BLIS; see also implement Fortran 2003 interface module for BLIS C API flame/blis#265.

For BLAS operations on accelerators (probably out of scope of fpm)

• cuBLAS - BLAS optimized for Nvidia GPU's
• rocBLAS - BLAS optimized for AMD GPU's
• clBLAS - OpenCL BLAS routines
• CLBLAST - OpenCL BLAS with C++11 API

Further specialized BLAS libraries are listed on Wikipedia.

Other BLAS variations (also out of scope?):

• PBLAS - Parallel BLAS
• Sparse BLAS - Sparse BLAS, several implementations available (MKL, gsl, AMD, librsb)
• PSBLAS - Parallel Sparse BLAS
• XBLAS - Extended precision BLAS
• GraphBLAS - API for graph algorithm based on linear algebra

Luckily, LAPACK variants are fewer:

• Netlib LAPACK - reference version
• Netlib LAPACK95 - Fortran 95 interface to LAPACK
• OpenBLAS - includes partially specialized LAPACK routines
• ReLAPACK - Recursive LAPACK (also included in OpenBLAS)
• Intel MKL LAPACK - Intel's optimized version; also exposes a Fortran 95 interface with small differences from the Netlib LAPACK95

Further vendor implementations of LAPACK are listed on Netlib. @14NGiestas has been working on a modern Fortran interface for BLAS and LAPACK. The debian page on LAPACK describes a few more caveats, one of them being the integer kind.

Libflame is a newer library for dense linear algebra, and also includes a compatibility layer lapack2flame that targets application relying upon the Fortran LAPACK API. Vendor versions such as AMD libFLAME are also appearing. Two more libraries for dense linear algebra that also target multicore processors and accelerators are PLASMA (Fortran interface available) and MAGMA.