Hi all, I think the update-alternatives configuration set up for openblas incorrectly/incompletely overrides an alternative for libblas.so.3. Namely, the libopenblas_pthreads provides an alternative for itself (libopenblas_pthreads.so.0), but then places a link to the more generic openblas library libopenblas.so.0. This overrides the alternatives set up for libblas, and gets picked up by e.g. cmake and its FindBLAS module. In short, here you can see the options available for libblas.so.3, and my override for the openmp version: $ update-alternatives --query libblas.so.3 Name: libblas.so.3 Link: /usr/lib64/libblas.so.3 Status: manual Best: /usr/lib64/blas/libblas.so.3 Value: /usr/lib64/libopenblas_openmp.so.0 Alternative: /usr/lib64/blas/libblas.so.3 Priority: 50 Alternative: /usr/lib64/libopenblas_openmp.so.0 Priority: 20 Alternative: /usr/lib64/libopenblas_pthreads.so.0 Priority: 20 But this value is overriden by libopenblas.so.0 $ ls -l /usr/lib64/*blas* | grep alternative lrwxrwxrwx 1 root root 30 Sep 11 2018 /usr/lib64/libblas.so.3 -> /etc/alternatives/libblas.so.3 lrwxrwxrwx 1 root root 31 Sep 11 2018 /usr/lib64/libcblas.so.3 -> /etc/alternatives/libcblas.so.3 lrwxrwxrwx 1 root root 43 Sep 11 2018 /usr/lib64/libopenblas.so.0 -> /etc/alternatives/libopenblas_pthreads.so.0 CMake will favor libopenblas, which is not necessarily a problem in and of itself, but I am trying to test an openmp application and cmake gets confused. I think this is an issue in how (open)blas is packaged. Ideally, either libblas should point to any available blas implementation (including the various libopenblas options), or blas should point to a generic libopenblas.so.0, which is itself an alternative that points to the available openblas libraries. Right now it's kind of doing both, and they end up conflicting. It would be simple enough to just remove the libopenblas_pthreads alternative and have libblas be in charge of all of them. I would be happy to submit a change if I knew where to look.