[LinearAlgebra] BLAS backend and update-alternatives

[cdluminate]

I'm raising the same topic as #27 again.

Debian family (including Ubuntu) highlights a feature named update-alternatives, which is used to switch symbol links between different providers. For example, any user could change the default BLAS/LAPACK backend as described here[1].

With this feature, many packages such as octave, numpy could switch BLAS backend smoothly because /usr/lib/x86_64-linux-gnu/libblas.so{,.3} is a symbol link managed by update-alternatives. Julia could also take advantage of this mechanism. However, when I'm trying to switch the underlying BLAS backend from openblas to MKL, this warning occurred. Then I disabled this feature for Debian's julia package.

The concerns about switching BLAS backend like this also includes ILP64 (as mentioned here: #27 ). The good news is that I'm working on Debian's BLAS64/LAPACK64 packages (bottom part of [1]), so the index length is not expected to be a problem if Julia is linked against BLAS64. Currently (in Debian archive) there are MKL and BLIS providing BLAS64 API/ABI.

Last but not least, this is a legal way to distribute pre-built Julia which could work with MKL without recompilation.

[1] https://wiki.debian.org/DebianScience/LinearAlgebraLibraries

[ViralBShah]

Right - the Julia blas interface tries to guess which vendor BLAS it is and tries to query for information accordingly. The update-alternatives is defeating that detection:

https://github.com/JuliaLang/julia/blob/8aeb398aff2e05c026a4d41568653b33c5ec4c89/stdlib/LinearAlgebra/src/LinearAlgebra.jl#L418

[ViralBShah]

We probably should have a more robust way to detect the blas. Perhaps check for presence of vendor specific symbol names.

[ViralBShah]

Going with FlexiBLAS should ideally fix this on all platforms in a much nicer way. Closing this in favour of that.