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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With