Dear all,
I am having a problem with compiling the latest build of LAMMPS pulled
today from the stable branch.
The configuration, with the files generated by using cmake-gui, goes OK
(see attached file). But the "make" part fails with the
"CMakeFiles/Makefile2:676: recipe for target 'CMakeFiles/gpu.dir/all'
failed" error:
[ 4%] Built target colvars
[ 4%] Building NVCC fatbin file
cuda_compile_fatbin_1_generated_lal_pppm_f.cu.fatbin
CMake Error at
cuda_compile_fatbin_1_generated_lal_pppm_f.cu.fatbin.RelWithDebInfo.cma
ke:211 (message):
Error generating
/scratch/mylammps/build/cuda_compile_fatbin_1_generated_lal_pppm_f.cu.f
atbin
CMakeFiles/gpu.dir/build.make:727: recipe for target
'cuda_compile_fatbin_1_generated_lal_pppm_f.cu.fatbin' failed
make[2]: *** [cuda_compile_fatbin_1_generated_lal_pppm_f.cu.fatbin]
Error 1
CMakeFiles/Makefile2:676: recipe for target 'CMakeFiles/gpu.dir/all'
failed
make[1]: *** [CMakeFiles/gpu.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2
I have found a similar problem in the LAMMPS mailing list from 2018,
but there were no solution to be found there.
Would appreciate any tips on how to go forward with the compilation and
whether using the "old-fashioned" method would be a better choice.
Regards
Dr. Tatiana Kuznetsova
University of Bergen
Bergen, Norway
cmake_build_config_output.txt (1.86 KB)
Please note “latest” != “stable”.
The problem is that with the information you provide, it is not possible to see what the actual failure is and what Linux version and CUDA version you are using. It could be a problem with your CUDA installation or an incompatibility or configuration mishap there.
You have two main options:
- try compiling with OpenCL instead of CUDA.
- use the “unstable” branch instead of “stable”. That has a significantly updated and more tested GPU code and build scripts (for both, CMake and GNU make).
Axel.
I am indeed on the stable branch, as verified by “git branch –list”
Linux: Ubuntu 18.04
CUDA 11.3
The first main option, how will using OpenCL affect GPU acceleration?
And, I though your team heavily encouraged the use of cmake instead of the “conventional” make?
Cheers and thanks for the tips
Tatana Kuznetsova
UiB, Bergen, Norway
I am indeed on the stable branch, as verified by “git branch –list”
Linux: Ubuntu 18.04
CUDA 11.3
The first main option, how will using OpenCL affect GPU acceleration?
difficult to say. should be mostly the same. there are some optimizations that OpenCL doesn’t have, but they affect different pair styles differently.
at any rate, it will be a small percentage.
And, I though your team heavily encouraged the use of cmake instead of the “conventional” make?
yes, we do. we want the CMake build process to be capable of doing everything as well or better than the conventional make procedure. however, there are still continuing improvements.
from the specs you provide, I suspect the major problem is that your CUDA version is much newer than your LAMMPS version, so the CMake script doesn’t know about it and cannot find the correct compilation settings for building “fat” binaries, i.e. binaries that are compatible with all GPU architectures that your specific version of the toolkit supports.
that CUDA toolkit version issue should be addressed in the “unstable” branch (I have been able to compile LAMMPS with CUDA 11.2 on Fedora 33). …and if not, the “unstable” version (27 May 2021 currently) has much improved OpenCL support (that also works well on Intel GPUs integrated into CPUs, BTW), so there should be a benefit to try out the more recent patch release for GPU acceleration (not to mention the continuing bugfixes and internal code improvements).
Axel.
One more comment on the CMake versus GNU make situation (also as a point of reference for other LAMMPS users reading this).
The reason why we are advertising CMake so much is that it takes a lot of the guesswork or having experience in compilation tools and editing makefiles out of the equation.
As it is demonstrated by your specific case, this works well for as long as the CMake scripting has been programmed accordingly to handle as many possible scenarios as feasible.
Despite having CMake support in LAMMPS now for several years, there are still corner cases that need updates to the CMake scripting. Most of the time this is when there are new or updated tools or libraries or sometimes even newer CMake versions change policies etc. (so we have to tell them which setting to use on those).
That said, if things go wrong in the CMake procedure, they are often easier to address with the GNU make procedure, because to use it you have to know more about your tools and OS and how to compile software in the first place and the modifications are similar to the adjustments that you would have to make anyway.
Bottom lines:
- more effort is spent on improving CMake support than on GNU make (most of the CMake-only features are particularly useful for developers, so it is less of a concern for somebody wanting to just use LAMMPS).
- We recommend using CMake as the first option to everybody who is not very familiar with how to modify makefiles and do multiple configuration / compilation / linking / make steps in the correct order. As CMake infers a lot of settings from your local machine and does the compilation in one go. Also we have presets “minimal” and “most” with combinations of packages that should be compilable without manual configuration
- we recommend people using CMake to try the “unstable” branch (i.e. follow the “patch” releases instead of the “stable” releases) as they are more up-to-date and thus have a more up-to-date CMake support
- it is more difficult to provide advice and support for the GNU make procedure since it is not easily possible to know what needs to be known about an individual machine to configure LAMMPS for compilation best. But there is no principal disadvantage to it. It is more a question of convenience.
which version of LAMMPS is this with?
Hello all,
I purged my previous Nvidia isetup, driver included, and installed CUDA SDK 11.3 (mostly because experience shows that even you tries to take a step back, Nvidia will insist on installing their latest version). The individual files did compile, and the only hitch now is the linker failure below.
According to this stackoverflow thread opengl - How to fix undefined reference to symbol 'dlclose@@GLIBC_2.2.5' from glad.c - Stack Overflow
I am supposed to add libdl with CMAKE_DL_LIBS
Would really appreciate instructions on doing this.
99%] Built target lammps
Consolidate compiler generated dependencies of target lmp
[ 99%] Linking CXX executable lmp
/usr/bin/ld: liblammps.a(molfile_interface.cpp.o): undefined reference to symbol ‘dlclose@@GLIBC_2.2.5’
//lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
CMakeFiles/lmp.dir/build.make:109: recipe for target ‘lmp’ failed
make[2]: *** [lmp] Error 1
CMakeFiles/Makefile2:449: recipe for target ‘CMakeFiles/lmp.dir/all’ failed
make[1]: *** [CMakeFiles/lmp.dir/all] Error 2
Makefile:135: recipe for target ‘all’ failed
make: *** [all] Error 2
Cheers
Tatiana Kuznetsova
Both stable and unstable branches pulled yesterday.
Cheers
TK
sorry, but it doesn’t make sense, that you get the exact same error with those two LAMMPS versions.
for the unstable branch, you should be able to work around the linker issue by either enabling the PLUGIN package (and ignoring the warning) or by disabling the USER-MOLFILE package. our integration tests either use both packages together or not and thus it was not noticed that they both need to link with the dynamic linker libs independently. somehow the one on the USER-MOLFILE package got dropped. this will be rectified in the next patch release.
as mentioned before, the stable branch is not compatible with CUDA 11.3 and requires edits to the CMake scripts that are only available in the unstable branch.
axel.