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
Update the change from commit f7f3d8987a (FindBLAS: Add dependency of
OpenBLAS on OpenMP for BLA_STATIC, 2020-11-10, v3.20.0-rc1~492^2):
* If C is not enabled, find CXX OpenMP libraries instead.
* Do not use BLA_STATIC's custom CMAKE_FIND_LIBRARY_SUFFIXES for OpenMP.
It can break projects that already call `find_package(OpenMP)` and
expect a shared library. Whether OpenMP is static is orthogonal to
whether BLAS is static.
Fixes: #22039
Issue: #16221
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.
The check added by commit 276b56f01c (FindBLAS: Add second try for
OpenBLAS with thread libraries., 2019-06-07, v3.15.0-rc2~5^2) can
work only when C or CXX is enabled.
Fixes: #20092
Recently, FindBLAS has been extended with additional library search
path based on the environment variable MKLROOT. However, the choice
of the Intel MKL architecture (IA-32 vs Intel64) was based on
unrelated (and possibly undefined) size of integer.
This commit changes the selection of the Intel MKL architecture to
instead consider the variable BLA_VENDOR, if available.
So, if the environment variable MKLROOT is defined and
BLA_VENDOR=Intel10_32, then $ENV{MKLROOT}/lib/ia32_<OS> will be added
to the search path (OS = lin, win, or mac).
Similarly, if MKLROOT is defined and BLA_VENDOR=Intel10_64lp or
BLA_VENDOR=Intel10_64ilp, then the path $ENV{MKLROOT}/intel64_<OS>
will be used.
If either MKLROOT or BLA_VENDOR is undefined, no additional search
path on top of LD_LIBRARY_PATH / DYLD_LIBRARY_PATH / LIB is be added.
According to Intel MKL Link Line Advisor, there is no GNU Fortran
interface library provided for OS X variant of Intel MKL. Because of
this missing library, FindBLAS was failing on OS X, looking for
nonexistent library libmkl_gf_[i]lp64.
To prevent this, FindBLAS will now always use Intel Fortran interface
for MKL on OS X (libmkl_intel_[i]lp64), even with GNU Fortran.
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
c259912b14 FindBLAS: Do not look for BLAS once BLAS95 has been found
d5f691be0b FindLAPACK: Additional libraries for MKL+gfortran combination
8b63265ea5 FindLAPACK: Unify internal variables related to MKL
ede1715c1d FindLAPACK: Remove MKL components already provided by MKL BLAS
03879b11af FindLAPACK: Prioritize Intel MKL
b4edf7b5d2 FindBLAS: Support 32bit Intel MKL 10.3+
fc149a72f7 FindBLAS: Support combination of gfortran and Intel MKL
f0d52f55f1 FindBLAS: Consolidate duplicated code related to MKL on Windows
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2633
When BLA_F95 is ON, FindBLAS looks for BLAS95_LIBRARIES (in Intel MKL).
As this is a superset of BLAS_LIBRARIES, if they are found, no further
search in other vendors is necessary.
Refactoring in commit v3.12.0-rc1~92^2 (FindPkgConfig: export the list
of found libraries also as variable, 2018-05-11) dropped use of FPHSA
to set `BLAS_FOUND`. Set it explicitly instead.
