Hi,
First, please note that I'm merely a happy user of Spack--the glory goes to others, and especially those making recent updates to the Amber recipe.
Looking again at a non-Spack build, I start with this (again, on RHEL 7.9)
spack load --first 'cmake.3.20.3' 'cuda.10.2.89'
and then run './run_cmake' on what I believe is a clean tree.
This fails with
-- Updater done. If you want to install updates, then set the APPLY_UPDATES variable to true.
-- Checking whether to use built-in libraries...
-- Looking for complex.h
-- Looking for complex.h - found
-- Looking for rl_initialize in libreadline.so
-- Looking for rl_initialize in libreadline.so - not found
-- Detailed information about why this check failed can be found in /packages/amber/amber20_src/build/CMakeFiles/CMakeError.log
-- Could NOT find Readline (missing: READLINE_WORKS)
CMake Error at cmake/3rdPartyTools.cmake:84 (message):
3rd party program readline is not bundled and cannot be built inside Amber.
Call Stack (most recent call first):
cmake/3rdPartyTools.cmake:189 (set_3rdparty)
CMakeLists.txt:190 (include)
These diagnostics aren't really correct. Looking in CMakeError.log, there seem to be two issues.
The latter is this
Determining if the function rl_initialize exists in the library failed with the following output:
Change Dir: /packages/amber/amber20_src/build/CMakeFiles/CMakeTmp
Run Build Command(s):/bin/gmake -f Makefile cmTC_83ce1/fast && /bin/gmake -f CMakeFiles/cmTC_83ce1.dir/build.make CMakeFiles/cmTC_83ce1.dir/build
gmake[1]: Entering directory `/gpfs/packages/amber/amber20_src/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_83ce1.dir/TryLinkLibrary.c.o
/bin/gcc -fPIE -std=gnu99 -o CMakeFiles/cmTC_83ce1.dir/TryLinkLibrary.c.o -c /packages/amber/amber20_src/build/CMakeFiles/CMakeTmp/TryLinkLibrary.c
In file included from /usr/include/readline/readline.h:35:0,
from /packages/amber/amber20_src/build/CMakeFiles/CMakeTmp/TryLinkLibrary.c:2:
/usr/include/readline/rltypedefs.h:64:28: error: unknown type name 'FILE'
typedef int rl_getc_func_t PARAMS((FILE *));
I'm inclined to agree with this comment that this is actually a bug in readline.
https://stackoverflow.com/questions/28008167/errors-when-trying-to-build-in-cygwin#comment55924212_29013068
There was also an earlier error
Run Build Command(s):/bin/gmake -f Makefile cmTC_ccb50/fast && /bin/gmake -f CMakeFiles/cmTC_ccb50.dir/build.make CMakeFiles/cmTC_ccb50.dir/build
gmake[1]: Entering directory `/gpfs/packages/amber/amber20_src/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_ccb50.dir/src.c.o
/bin/gcc -DCMAKE_HAVE_LIBC_PTHREAD -fPIC -std=gnu99 -o CMakeFiles/cmTC_ccb50.dir/src.c.o -c /packages/amber/amber20_src/build/CMakeFiles/CMakeTmp/src.c
Linking C executable cmTC_ccb50
/gpfs/packages/spack/spack/opt/spack/linux-rhel7-broadwell/gcc-8.2.0/cmake-3.20.3-elxnmcva6scgvkhjgci4yfkhnjqkdj4a/bin/cmake -E cmake_link_script CMakeFiles/cmTC_ccb50.dir/link.txt --verbose=1
/bin/gcc -fPIC CMakeFiles/cmTC_ccb50.dir/src.c.o -o cmTC_ccb50
CMakeFiles/cmTC_ccb50.dir/src.c.o: In function `main':
src.c:(.text+0x2f): undefined reference to `pthread_create'
src.c:(.text+0x3b): undefined reference to `pthread_detach'
src.c:(.text+0x47): undefined reference to `pthread_cancel'
src.c:(.text+0x58): undefined reference to `pthread_join'
src.c:(.text+0x6c): undefined reference to `pthread_atfork'
collect2: error: ld returned 1 exit status
gmake[1]: *** [cmTC_ccb50] Error 1
gmake[1]: Leaving directory `/gpfs/packages/amber/amber20_src/build/CMakeFiles/CMakeTmp'
gmake: *** [cmTC_ccb50/fast] Error 2
I'm uncertain whether this is an actual failure or just a failed attempt to find pthread in one place, perhaps followed by a second successful attempt later.
I briefly tried loading Spack 'readline', but this doesn't immediately work. In general, Spack libraries don't export CPATH/LIBRARY_PATH/etc, and I doubt 'cmake' will attend to them anyway.
Hence the next step, which is to retry the Spack amber recipe, which has improved since I last tried it a few months ago.
Regarding the CUDA gencode options, it looks like these might be set in a lot of places, and I'm not sure all of these are cross-consistent:
$ ls -ld $(fgrep -rle compute_50 amber20_src/)
-rwxr-xr-x 1 mcolema5 swmgr 164819 Apr 27 2021 amber20_src/AmberTools/src/configure2
-rwxr-xr-x 1 mcolema5 swmgr 85502 Apr 26 2021 amber20_src/AmberTools/src/cpptraj/configure
-rw-r--r-- 1 mcolema5 swmgr 19559 Aug 1 2019 amber20_src/AmberTools/src/cusplibrary-cuda9/testing/vs_tester/device_cuda_tester/device_cuda_tester.vcxproj
-rw-r--r-- 1 mcolema5 swmgr 5646 Apr 26 2021 amber20_src/AmberTools/src/quick/cmake/CudaConfig.cmake
-rwxr-xr-x 1 mcolema5 swmgr 43857 Apr 26 2021 amber20_src/AmberTools/src/quick/configure
-rw-r--r-- 1 mcolema5 swmgr 7090 Apr 26 2021 amber20_src/AmberTools/src/quick/quick-cmake/QUICKCudaConfig.cmake
-rw-r--r-- 1 mcolema5 swmgr 5749 Apr 26 2021 amber20_src/cmake/CudaConfig.cmake
Hard to know what to suggest, but it would be nice if there was just one place where the gencode options were configured. Certainly, guidance would be handy on which options are best and are possible for each card and version of CUDA. And of course, an obvious diagnostic if this should fail.
Regards,
Mike
-----Original Message-----
From: David A Case <david.case.rutgers.edu>
Sent: Monday, January 24, 2022 6:27 AM
To: AMBER Mailing List <amber.ambermd.org>
Subject: Re: [AMBER] any working singularity or docker recipe? (esp for CUDA and MPI)
On Sun, Jan 23, 2022, Michael Coleman wrote:
>
>The documented Amber build procedure isn't working for us
It would be great (if you have the time) to see what is going wrong with
the regular build procedure. Is it this problem?
>The 'cuda.10.2.89' works around an exasperating undocumented behavior of
>the Amber build, which is that GPU code is generated or not generated for
>different cards depending on the CUDA version number. In particular, K80
>code is not generated for CUDA 11, even though CUDA 11 supports K80s. The
>Amber code doesn't fail obviously for lack of this code, but rather one
>gets an obscure diagnostic.
For Amber developers: is there a reason that support for SM3.0 is turned
off for Cuda 11 (in CudaConfig.cmake)? Note that (officially?) the K80
card is supposed to use SM3.7, but there is a comment (outdated?) in
CudaConfig.cmake that SM3.0 "may be better". But then we turn off SM3.0 for
Cuda 11, and never use SM3.
For Mike: if the above is the problem, you might try just editing
CudaConfig.cmake for your installation to allow either SM3.0 or SM3.7 code
to be generated. And if other things are problematic, it would good to know
about them. In any event, thanks for your work on this, including on spack.
....dac
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
https://urldefense.com/v3/__http://lists.ambermd.org/mailman/listinfo/amber__;!!C5qS4YX3!UpMAKAb3rwhBqwoehq1ICeHu5j6DYheRagOWjvbbuXdlSxGNZVJ4Q1Ivu9W1TJH0pwE$
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon Jan 24 2022 - 16:00:02 PST
