Build errors with spack due to automatic detection of cray-libsci

[climbfuji]

Description

The automatic detection of cray-libsci in cmake/ectrans_find_lapack.cmake doesn't work (well or at all) with spack when the Cray compiler wrappers are omitted as per HPE recommendations (https://cpe.ext.hpe.com/docs/latest/craype/spack.html).

ectrans/cmake/ectrans_find_lapack.cmake

Line 16 in 163ae8e

# Following libsci code should disappear soon, with more recent cmake versions (needs more investigation)

This is because the cray-libsci library is loaded automatically as part of the Cray modules, and even spack can't suppress that. But spack sanitizes the linker paths etc, which ultimately leads to an error -lsci - library not found.

If MKL is used, there is no issue, but in situations where we want to use some other LAPACK provider like openblas, the above happens. Instead of detecting libsci automatically, even if the user doesn't want to use it, the logic below (use cmake find lapack) should be used.

Reading the comment in cmake/ectrans_find_lapack.cmake correctly, a certain minimum version of cmake is required. Which version exactly do you need?

I created a bug fix PR in spack https://github.com/spack/spack-packages/pull/1946/files that comments out the libsci logic in cmake/ectrans_find_lapack.cmake, and I would also like to update the cmake requirement as part of this PR.

Notes

• I will be on leave Oct 11-20. I can add the cmake requirements into the spack PR after my return.
• I tested the PR as is (hash spack/spack-packages@7846a5f) on a system with cmake 3.31.8, and it correctly linked against the LAPACK provider from spack (openblas)

[samhatfield]

Hi @climbfuji - thanks for looking into this. As you can probably tell, we have not investigated this since implementing this workaround. So we can determine whether the latest minimum CMake version required by ecTrans (3.25) resolves this for us, could you tell us if it's possible to reproduce this issue outside of Spack? Are you building on e.g. Frontier? If so, we should be able to reproduce it on LUMI, which will help us to debug what's going on.

[climbfuji]

I think the easiest solution would be for me to test with cmake 3.25 in spack. If that solves the issue, then the workaround can be removed safely?

[climbfuji]

I was able to build ectrans with cmake @3.25 with the patch introduced in https://github.com/spack/spack-packages/pull/1946/files using cmake@3.25.3. It looks like it is safe to remove the workaround in cmake/ectrans_find_lapack.cmake once you require cmake 3.25 for ectrans (which you just did for 1.7.0).

[samhatfield]

I think you're probably right that we can now remove it. @wdeconinck - do you know the history of this cray-libsci workaround? Is there a reason to keep it?