# findblas with MKL and gnu compilers
**URL:** https://discourse.cmake.org/t/findblas-with-mkl-and-gnu-compilers/6764
**Category:** Usage
**Tags:** os:linux
**Created:** [October 31, 2022, 4:25pm UTC](https://discourse.cmake.org/t/findblas-with-mkl-and-gnu-compilers/6764 "2022-10-31T16:25:40Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@noam.bernstein](https://discourse.cmake.org/u/noam.bernstein)
#### Post date: [October 31, 2022, 4:25pm UTC](https://discourse.cmake.org/t/findblas-with-mkl-and-gnu-compilers/6764/1 "2022-10-31T16:25:40Z")
I’m using cmake with findblas to compile LAMMPS, and while it finds the correct compiler (g++/gfortran) and BLAS (MKL), it gets the wrong set of libraries. In particular, it appears that the name of the “top level” blas library is hard-wired to `libmkl_intel_lp64.so`, while the gnu compiler requires `libmkl_gf_lp64.so`. This seems like a findblas bug to me, but I’m not sure how to go about reporting or fixing it.
[edited to remove side-issue which was actually caused by a small bug in our environment]
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [November 1, 2022, 8:09pm UTC](https://discourse.cmake.org/t/findblas-with-mkl-and-gnu-compilers/6764/2 "2022-11-01T20:09:10Z")
The `find_library(NAMES)` argument would be where I’d start to look myself.
---
### Author:  [@noam.bernstein](https://discourse.cmake.org/u/noam.bernstein)
#### Post date: [November 1, 2022, 8:26pm UTC](https://discourse.cmake.org/t/findblas-with-mkl-and-gnu-compilers/6764/3 "2022-11-01T20:26:06Z")
I just realized (when looking through for the function you mention) that [CMake/FindBLAS.cmake at master · Kitware/CMake · GitHub](https://github.com/Kitware/CMake/blob/master/Modules/FindBLAS.cmake#L449) does actually attempt to set the string to “gf”. I guess the question may be why, in the case of LAMMPS, that if clause does not end up being used.
There are various other places where the “intel” is hardwired, but on second look it may only be for Windows, which shouldn’t be affecting my use case.
---
### Author:  [@noam.bernstein](https://discourse.cmake.org/u/noam.bernstein)
#### Post date: [November 1, 2022, 8:41pm UTC](https://discourse.cmake.org/t/findblas-with-mkl-and-gnu-compilers/6764/4 "2022-11-01T20:41:49Z")
Aha - it needs to have fortran enabled, and it wasn’t doing that. It’s easy enough to work around with our `CMakeLists.txt`, by adding `enable_language(Fortran)` before calling `find_package(blas)`.
In this case the calling functions really are in Fortran, so the `enable_language(Fortran)` call makes sense, but I don’t know what would happen if the calling program was in C/C++. It may be helpful if FindBLAS had a more robust way to detect whether intel or gnu compilers are being used.
---
### Author:  [@noam.bernstein](https://discourse.cmake.org/u/noam.bernstein)
#### Post date: [November 1, 2022, 9:42pm UTC](https://discourse.cmake.org/t/findblas-with-mkl-and-gnu-compilers/6764/5 "2022-11-01T21:42:28Z")
Note that to the best of my understanding, as FindBLAS currently stands I don’t see any sensible way for a pure C/C++ code to ask cmake for BLAS. It would have to ask for fortran language support, but there might not even be a fortran compiler installed on the system.
[edited - I guess it’s possible that if Fortran really isn’t being used, which of the two possible MKL variants is linked to doesn’t matter, in which case the choice is moot]