Now that `CHECK_{BLAS,LAPACK}_LIBRARIES` are functions, we can set
`CMAKE_FIND_LIBRARY_SUFFIXES` locally without affecting the global
state. This avoids the need for local state switching that was added in
commit 9ef82d95d8 (FindBLAS: Fix detection of OpenMP as dependency of
BLA_STATIC, 2021-04-07, v3.20.1~3^2), so remove that.
Refactoring in commit 4c74c86f40 (FindBLAS/LAPACK: Add support for the
Fujitsu SSL2 library, 2021-01-27) was done in order to support calling
`find_library` on the dependencies as well as the candidate libraries.
However, it broke a few things:
* Intel MKL's BLAS/LAPACK are no longer found. We specify their
dependencies using `-l...` flags, so we should not try to use
`find_library` for them.
* The dependencies are repeated because we accumulate them in the
`find_library` search loop and then append them at the end too.
Revert the incorrect part of the refactoring. Retain the flags part
needed for the Fujitsu vendor.
Fixes: #22056
This also does some additional work to fix issues with
libraries provided only via compiler options and no explicit
library names.
Co-Author: Yuichiro Utsumi <utsumi.yuichiro@jp.fujitsu.com>
The patch also updates the documentation to explicitly state
that Intel10_32 stands for threaded case (linked with Intel OpenMP).
Later, one may need to add Intel10_32_seq to support linking
with the sequential version of Intel MKL.
Fixes: #20857
Even though Intel MKL typically puts the libraries under
`$MKLROOT/lib/$arch_$os` some installations may still use
`$MKLROOT/lib/$arch/` path. Ideally, `$arch` should be a
symlink to `$arch_$os`, but sometimes the opposite happens
(for instance, see Intel MKL distribution in Arch Linux [1]),
and sometimes only `$arch` directory alone is present.
This patch extends the search list with `$MKLROOT/lib/$arch` with
lower priority than `$MKLROOT/lib/$arch_$os`, as the latter is the
official path to Intel MKL libraries.
It is also worth mentioning that Intel MKL Link Line Adviser [2]
recommends using `$MKLROOT/lib/$arch` directory in a link line:
```
-L${MKLROOT}/lib/intel64 -Wl,--no-as-needed -lmkl_intel_lp64
-lmkl_sequential -lmkl_core -lpthread -lm -ldl
```
[1] https://www.archlinux.org/packages/community/x86_64/intel-mkl/files/
[2] https://software.intel.com/content/www/us/en/develop/articles/intel-mkl-link-line-advisor.html
This is required if MKLROOT points to the subdirectory .../mkl/ instead of
the root of an Intel MKL library installation. Only in this case the MKL
will be searched starting from the parent directory, to detect relevant
dependencies in parallel subdirectories, like 'compiler' and 'tbb'.
Previously the search in the dynamic linker paths 'LIB', 'LD_LIBRARY_PATH'
and 'DYLD_LIBRARY_PATH' was dependent on the value of the environment
variable 'MKLROOT'. If MKLROOT was given, the dynamic linker paths where
not searched. This seems slightly counter-intuitive.
This PR changes the behavior so that MKLROOT is searched first, but if
unsuccesful, the dynamic linker paths are tried as well.
Bring whitespace and code style up to date in these scripts. Both
scripts share the same origin but have diverged over time, so
synchronize them again. This is relevant because BLAS and LAPACK
detection is often performed simultaneously, so both scripts should
evolve in sync. While at it, update a few comments.
This update is intended to have no functional changes.
Fix the condition added by commit 68dcbeee01 (FindLAPACK: Test for
implicitly linked LAPACK libraries, 2019-06-11, v3.16.0-rc1~560^2) to
use BLAS libraries if they are sufficient with no dedicated LAPACK
libraries.
Fixes: #20099
Apply the change from commit 5b8f69ebe9 (FindBLAS: Detect implicitly
linked BLAS library, 2018-08-28, v3.13.0-rc1~150^2~2), to FindLAPACK
also. Typically both BLAS and LAPACK are provided the same way,
e.g. in a Cray Compiler Environment.
be7b30f67e Find{BLAS,LAPACK}: Add note and example for using Intel MKL
b323407235 Find{BLAS,LAPACK}: Update docs to use modern conventions
ba30b94435 FindLAPACK: Remove extra indentation from a line
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2880
As per Intel MKL command line advisor, "libdl" is added to the list of
libraries that provide LAPACK functionality. Furthermore, the implicit
link directories are added to the searched libraries to allow finding
of "libgomp".
A surplus library libmkl_gf_... has been removed from the LAPACK
libraries serach path (when relevant, it is already provided by BLAS).
Similarly, the thread libraries do not need to be explicitly added to
the implicit LAPACK libraries, as they are already included in the
list (via BLAS libraries provided by FindBLAS).
f1a3e4eca8 FindLAPACK: Correct library name and symbol searched in LAPACK95 wrapper
970b18e9a5 FindBLAS: Correct symbol searched in BLAS95 wrapper
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2560
The symbol "CHEEV", originally used to determine if a library provides
Fortran 95 wrappers for LAPACK, has been replaced by "cheev_f95". "CHEEV"
is provided by libmkl_intel_(i)lp64, which does not provide the generic
Fortran 95 wrappers. Instead, libmkl_lapack95_(i)lp64 does; one of the
specializations of the type-generic interfaces contained in that library
is "lapack_f95".
Also, FindLAPACK used libmkl_intel_(i)lp64 instead of the correct
libmkl_lapack95_(i)lp64 library for LAPACK95 functionality. This has
been fixed, too.
