Summary: | dev-build/cmake: Gentoo patch breaks FindBLAS for development | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Lucas Hosseini <lucas.hosseini> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | kaikaikai, kde, sam, wtt6 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=835799 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Lucas Hosseini
2020-08-09 17:11:18 UTC
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 |