fix how --sysroot is taken into account in CMakeMake easyblock

[boegel]

(created using eb --new-pr)

The fix in #2247 was way too naive, and according to the CMake docs CMAKE_SYSROOT can only be specified in a toolchain file.

I've also added setting -DCMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX=64 to fix a problem where libraries like libpthread.so was not being found when installing LLVM, because it was located in ${EPREFIX}/usr/lib64 (on aarch64), rather than in ${EPREFIX}/usr/lib (like it is on x86_64).

This manifested as follows:

error: undefined reference to 'pthread_getspecific'

After a bit of digging, I noticed this in CMakeCache.txt:

LLVM_PTHREAD_LIBRARY_PATH:FILEPATH=LLVM_PTHREAD_LIBRARY_PATH-NOTFOUND

In a working environment (with libpthread.so in ${EPREFIX}/usr/lib), this was:

LLVM_PTHREAD_LIBRARY_PATH:FILEPATH=/cvmfs/pilot.eessi-hpc.org/2020.10/compat/x86_64/usr/lib/libpthread.so

Thanks a lot to @zao for the help in figuring out this unholy mess...

[boegel]

Hmm, this PR breaks the installation of GROMACS, it fails to find the FFTW libraries for some reason when using -DCMAKE_TOOLCHAIN_FILE=<builddir>/toolchain.cmake -DCMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX=64

-- Checking for module 'fftw3f'
--   Found fftw3f, version 3.3.8
Could not find fftw3f library named libfftw3f, please specify its location in CMAKE_PREFIX_PATH or FFTWF_LIBRARY by hand (e.g. -DFFTWF_LIBRARY='/path/to/libfftw3f.so')
CMake Error at cmake/gmxManageFFTLibraries.cmake:92 (MESSAGE):
  Cannot find FFTW 3 (with correct precision - libfftw3f for mixed-precision
  GROMACS or libfftw3 for double-precision GROMACS).

The libraries are there though, in ${EBROOTFFTW}/lib, and lib64 is a symlink to lib in there...

[boegel]

Similar issue with netCDF, where the Szip library is not found (despite the location being passed explicitly via -DSZIP_LIBRARY=$EBROOTSZIP/lib/libsz.so:

CMake Error at CMakeLists.txt:740 (MESSAGE):
  HDF5 Requires SZIP, but cannot find libszip or libsz.

And with CGAL, where Boost is not found anymore:

CMake Error at /cvmfs/pilot.eessi-hpc.org/2020.10/software/aarch64/generic/software/CMake/3.16.4-GCCcore-9.3.0/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
  Could NOT find Boost (missing: Boost_INCLUDE_DIR) (Required is at least
  version "1.48")
Call Stack (most recent call first):
  /cvmfs/pilot.eessi-hpc.org/2020.10/software/aarch64/generic/software/CMake/3.16.4-GCCcore-9.3.0/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
  /cvmfs/pilot.eessi-hpc.org/2020.10/software/aarch64/generic/software/CMake/3.16.4-GCCcore-9.3.0/share/cmake-3.16/Modules/FindBoost.cmake:2179 (find_package_handle_standard_args)
  cmake/modules/CGAL_SetupBoost.cmake:50 (find_package)
  cmake/modules/CGAL_SetupDependencies.cmake:85 (include)
  CMakeLists.txt:683 (include)

So somehow using -DCMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX=64 is messing things up.

Perhaps a better approach is to add ${EPREFIX}/usr/lib, ${EPREFIX}/usr/lib64, ${EPREFIX}/lib and ${EPREFIX}/lib64 to $CMAKE_SYSTEM_LIBRARY_PATH, like they do in the patch used by Gentoo?

[boegel]

Patching CMake itself is probably a better way forward, see #2248 ...

[Flamefire]

To help in checking what went wrong: https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_DEBUG_MODE.html
-> cmake --debug-find shows the paths searched and hence the effects of what is done here

Edit: Judging from the code: Setting CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX overwrites the default choice of adding lib<suffix> dirs. It is even possible, that no architecture specific paths are added by default, e.g. if "/etc/debian_version" exists

[boegel]

Closing this, the fix in #2248 has proven to be a better approach...