The `FindBLAS` CMake module supports options `BLA_VENDOR` (which enables one to specify a BLAS implementation), and `BLA_PREFER_PKGCONFIG` (which controls whether pkg-config should be used to do the lookup). The Gentoo ebuild has a patch that overrides used input for `BLA_PREFER_PKGCONFIG`: ``` +# first, try PkgConfig +set(BLA_PREFER_PKGCONFIG On) ``` This breaks CMake projects using `FindBLAS` with `BLA_VENDOR` set and `BLA_PREFER_PKGCONFIG=OFF`, since the `BLA_VENDOR` constraint will not be used as `BLA_PREFER_PKGCONFIG=OFF` gets overridden. A simple fix would be to replace the above with: ``` if(NOT DEFINED BLA_PREFER_PKGCONFIG) set(BLA_PREFER_PKGCONFIG ON) endif() ``` This would still override upstream CMake defaults, and would need any CMake project using `FindBLAS` to accomodate for Gentoo's customization, but at least it would give them a way to, unlike now. A real fix would be to remove this tweak altogether, and patch each Gentoo CMake project that calls `FindBLAS` to `set(BLA_PREFER_PKGCONFIG ON)` before the `find_package(BLAS)` call.
It would help to see an example of the failure (inc. any relevant CMakeError/Info.txt files, but also the full build.log + emerge --info).
I may have not been clear in my explanations: up to CMake 3.17, Gentoo patches the `FindBLAS` module in such a way (https://github.com/gentoo/gentoo/blob/master/dev-util/cmake/files/cmake-3.17.0_rc1-FindBLAS.patch) that the default behavior in Gentoo differs from the default behavior in upstream CMake. More specifically, this materializes when the input variable `BLA_PREFER_PKGCONFIG` is set to `OFF`: outside of Gentoo pkg-config is then not used, while in Gentoo, it is used regardless as (`BLA_PREFER_PKGCONFIG` is overridden by the patch and set to `ON` despite the user explicitly setting it to `OFF`).
I was wondering why this is useful but it's because of e.g.: [22:38:54] <beauby> sam_: Yeah sorry I got distracted :D My use-case is not for Gentoo components, but using CMake to build third party projects (specifically one library that explicitly relies on mkl)
Thanks Sam. To expand on the above remark, the use-case would be using CMake to build third-party projects (not ebuilds) that explicitly depend on a specific BLAS implem (for instance MKL) without forcing the user to change their system-wide default BLAS implem.
With Gentoo's new runtime-switchable blas system, it seems that the pkgconfig results are not affected by what provider is selected. This seems to mean that it is now impossible to compile a CMake project against any provider except the reference implementation.
Hi. I'm hitting this problem with llama.cpp. A simple example where the gentoo patch breaks cmake's detection of openblas is an empty project with CMakeLists.txt: *** cmake_minimum_required(VERSION 3.10) project(test) set(BLA_VENDOR OpenBlas) find_package(BLAS) if (BLAS_FOUND) message(STATUS "BLAS found:") message(STATUS " Libraries: ${BLAS_LIBRARIES}") message(STATUS " Include dirs: ${BLAS_INCLUDE_DIRS}") message(STATUS " Linker flags: ${BLAS_LINKER_FLAGS}") endif() *** The output has nothing to do with openblas: -- BLAS found: -- Libraries: /usr/lib64/libblas.so -- Include dirs: -- Linker flags: The root problem seems to be with cmake: if BLA_PREFER_PKGCONFIG is set, then cmake is ignoring BLA_VENDOR and isn't finding the right blas. But anyway, the gentoo patch breaks FindBLAS in cmake
I worked around this in guru with a (completely wrong but working) patch: https://gitweb.gentoo.org/repo/proj/guru.git/tree/sci-misc/llama-cpp/files/blas-ld.diff
This bug is nicely summarized by Michał Górny in https://bugs.gentoo.org/835799#c6: Gentoo shouldn't be patching CMake to override upstream behavior. This is against the principle of least surprise. This is especially harmful to software developers that are going to see inconsistent behavior between Gentoo and other distributions.
I created a pull request https://github.com/gentoo/gentoo/pull/40709 It is ugly and does not really solve the problem, but it allows to restore the upstream behavior when needed
