On Mon, Jan 24, 2022, Michael Coleman wrote:
>and then run './run_cmake' on what I believe is a clean tree.
>
>This fails with
>
>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 *));
Can you say (again?) what OS and version you are using? The error is in
your system /usr/include/readline/readline.h file (at line 35).
>src.c:(.text+0x6c): undefined reference to `pthread_atfork'
>collect2: error: ld returned 1 exit status
>gmake[1]: *** [cmTC_ccb50] Error 1
>
>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.
This doesn't look like an error. CMake gives lots of info about what it is
doing, many of which can look like errors.
>
>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 85502 Apr 26 2021 amber20_src/AmberTools/src/cpptraj/configure
>-rw-r--r-- 1 mcolema5 swmgr 5646 Apr 26 2021 amber20_src/AmberTools/src/quick/cmake/CudaConfig.cmake
>-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.
Thanks for the comment. The file you want is the last one listed. The
other files arise from the fact that the "upstream" versions of cpptraj and
quick are actually separate from Amber, and just bundled in. We can try to
make that bundling process smoother.
As for diagnostics, this is beyond my sphere of knowledge. We don't know at
compile time what GPU card will be used. Since it's printed in the output,
the code knows about this, and I suspect that this happens before any Amber
cuda code is executed. So, it seems possible that we could store the
allowed values in the executable, and try to get a better error message.
But it also seems like a big task.
Thanks for the report...dac
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Jan 25 2022 - 06:30:03 PST
