Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • CMake CMake
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 4,166
    • Issues 4,166
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 13
    • Merge requests 13
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • External wiki
    • External wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • CMakeCMake
  • CMakeCMake
  • Merge requests
  • !2312

FindBLAS: Handle compilers that implicitly link BLAS libraries

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Hubertus van Dam requested to merge hjjvandam/cmake:FindBLAS-implicit-blas-final into master Aug 24, 2018
  • Overview 14
  • Commits 4
  • Pipelines 4
  • Changes 1

On HPC systems, such as built by Cray (e.g. Cori (NERSC), Titan (ORNL), etc.) "compilers" may actually be compiler wrappers that implicitly link commonly used libraries. Examples of such libraries are MPI, BLAS, and LAPACK. FindBLAS.cmake was not aware of this possibility causing either CMake to fail when it did not find a BLAS library (even though this is not explicitly needed), or CMake might find an alternate BLAS library causing link time conflicts. The changes introduced have FindBLAS.cmake check first if BLAS is implicitly linked (in which case BLAS will be marked as found but BLAS_LIBRARIES will be empty), otherwise it will proceed with the usual approach of searching for commonly used BLAS libraries. One additional change was required because the code block for the Intel MKL detection was not protected by an if-statement to preserve prior found BLAS libraries. As the MKL libraries were searched for last they would take precedence over everything else. Hence adding that if-statement as needed to protect the detection of implicitly linked BLAS libraries caused a change in semantics such that all other BLAS libraries take precedence over the Intel MKL libraries. This was subsequently fixed by moving the Intel MKL detection forward so that this library is now the first one checked for (after checking for implicitly linked BLAS libraries). So no the order of priority is: implicitly linked BLAS libraries, Intel MKL, everything else just as before.

Edited Aug 27, 2018 by Brad King
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: FindBLAS-implicit-blas-final