In a Java project I am using matrix-toolkits-java (MTJ) for efficient matrix multiplication. This relies on netlib-java, which in turn relies on an optimized implementation of BLAS and LAPACK installed on the machine. It specifically looks for /usr/lib64/libblas.so.3 and /usr/lib64/liblapack.so.3 to find these libraries.
When installing blas and lapack via Yum, we get symbolic links /usr/lib64/libblas.so.3 and /usr/lib64/liblapack.so.3 pointing to the .so files from the reference blas and lapack installed via Yum.
Now we want to use implementations that are faster than the reference ones, in my case OpenBLAS. Irrelevant of whether I compile that myself, or install it via Yum, I end up with /usr/lib64/libopenblas-r0.2.18.so.
Now, according to any guide on the internet I am supposed to replace the symlinks to the reference implementation with symlinks to the OpenBLAS implementation, ending up with something like this:
libblas.so.3 -> libopenblas-r0.2.18.so
liblapack.so.3 -> libopenblas-r0.2.18.so
Okay, I can do that! I can do that with ln, or via alternatives. And if I do that, my code is happily using the fast OpenBLAS.
However, when ldconfig runs my awesome symbolic links are gone, they are overwritten by the reference BLAS and LAPACK installations. And then my software is sad and slow again.
So my question is, how to install OpenBLAS on CentOS/Fedora in such a way that running ldconfig will not destroy it? I can not remove the blas and lapack packages, as other clients of the host might rely on it. Rather I would somehow make the OS understand that OpenBLAS is an drop-in alternative to blas and lapack.
This article proposes installing openblas-compat via Yum. That fixes the issue for me. After installing the default blas package my software was still using OpenBLAS.