BLAS_LIBRARIES always present in ghost-config.cmake

Issue #223 resolved
Martin Galgon created an issue

Since it's set by findLAPACK in CMakeLists.txt, no matter what. If the LAPACK library already has a dependency on some other BLAS library, they will cause a clash at some point.

Comments (15)

  1. Moritz Kreutzer

    So, is this a bug in findLAPACK or in GHOST? If the latter, what should we do about this?

    I can't easily reproduce it since I'm always working on the RRZE systems with MKL, so I would be glad if you could provide a hint or even a fix.

  2. Martin Galgon reporter

    It's a bug with how the variable BLAS_LIBRARIES is handled. Whether this is a bug in findLAPACK or GHOST is debatable. It's content is set by findLAPACK and placed in ghost-config.cmake, where it is read from other cmake projects (is this case PHIST) and set as dependency, even if the detected LAPACK libraries actually depend on a different BLAS library. I'll think of a proper way to handle this, but don't have time right now. For now, the workaround is to remove the lines referring to BLAS_LIBRARIES from ghost-config.cmake in the install directory.

  3. Martin Galgon reporter

    A quick fix might be to simply unset BLAS_LIBRARIES in the case of a custom BLAS as per the BLAS cmake switch. In this case the user can at least control all BLAS references and make them match. Currently, if the BLAS is set to custom, just some reference to some BLAS library appears in ghost-config.cmake. Another way to deal with this may be to also defer linking of LAPACK(e).

  4. Moritz Kreutzer

    And why don't you just unset the BLAS_LIBRARIES via "ccmake"?

    If I understand you right, you would like to have something like this:


    Is that correct?

  5. Martin Galgon reporter

    Wouldn't the variable still be set by the find_package call?

    Anyway, it seems like the kind of BLAS library is controlled by CBLAS_H (formerly was BLAS). If no cblas header is found, it is assumed to be supplied by the application linking with GHOST. In this case, maybe the BLAS_LIBRARIES variable has to be unset after it has been set by the find_package(LAPACK) call. I have not tested this, though.

  6. Martin Galgon reporter

    I will, but it may take a while until I have time to play with this. Maybe push the milestone back to 0.10.0 since it is kind of a corner case if you are clearing issues for 0.9.0.

  7. Moritz Kreutzer


    There will be no 0.10.0. The next milestone will be 1.0 including a bunch of API changes.

    It will not be called 1.0 because it is stable, but rather to identify those API changes and simplify cooperation with our new project partners.

  8. Log in to comment