The BLA_PREFER_PKGCONFIG switch is not that useful if you are not able
to specify the pkg-config package to use. This adds BLA_PKGCONFIG_BLAS
and BLA_PKGCONFIG_LAPACK to that effect, allowing user choice in
environments that install differing variants of the BLAS libraries
with distinct .pc file names.
This is part of work to get more standardized installations of the
BLAS libs with specific names, likely blas.pc and lapack.pc only
for Netlib reference code, or maybe blas-netlib.pc and lapack-netlib.pc,
in any case distinct from choices like openblas-openmp.pc.
With Cray compiler wrappers (implicitly tested on OLCF Spock) the
BLAS and LAPACK libraries are automatically linked as necessary through
the wrapper script and programming environment. With this change, the
configure output is:
```
-- Found BLAS: implicitly linked
<snip>
-- Found LAPACK: implicitly linked
```
rather than
```
-- Found BLAS: 1
<snip>
-- Found LAPACK: LAPACK_LIBRARIES-PLACEHOLDER-FOR-EMPTY-LIBRARIES
```
Logic added by commit 4c74c86f40 (FindBLAS/LAPACK: Add support for the
Fujitsu SSL2 library, 2021-01-27, v3.21.0-rc1~402^2~1) accidentally
expressed a boolean condition without proper grouping. The pattern was
then copied by commit 2c9e623e31 (Find{BLAS,LAPACK}: Add support for the
NVHPC LAPACK library, 2021-05-05, v3.21.0-rc1~192^2). The resulting
logic incorrectly tries Fujitsu and NVHPC vendors even after results are
found from another vendor, and then erases those. Fix the grouping.
Fixes: #22403
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
