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]
find_library(NAMES) argument would be where I’d start to look myself.
I just realized (when looking through for the function you mention) that CMake/FindBLAS.cmake at master · Kitware/CMake · GitHub 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.
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
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.
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]