Lto-wrapper error compiling GROMACS 2024.2

User discussions
1

GROMACS version: 2024.2
GROMACS modification: No
I just set up a new Arch Linux machine and wanted to compile GROMACS 2024.2 with CUDA, based on the most recent PKGBUILD from the AUR package, with -DGMX_GPU=CUDA.

I get the following lto-wrapper error during compilation:

[ 92%] Linking CXX shared library ../../lib/libgromacs.so
/usr/src/debug/gromacs/gromacs-v2024.2/src/gromacs/selection/selvalue.cpp: In function ‘_gmx_selvalue_reserve’:
/usr/src/debug/gromacs/gromacs-v2024.2/src/gromacs/selection/selvalue.cpp:100:47: warning: argument 1 value ‘18446744073709551615’ exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
/usr/lib/gcc/x86_64-pc-linux-gnu/13.3.0/include/c++/new:128:26: note: in a call to allocation function ‘operator new []’ declared here
  128 | _GLIBCXX_NODISCARD void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc)
      |                          ^
{standard input}: Assembler messages:
{standard input}:10801: Error: symbol `fatbinData' is already defined
{standard input}:20715: Error: symbol `fatbinData' is already defined
(...)
make[3]: *** [/tmp/ccIxNyfJ.mk:2: /tmp/ccusUXZ8.ltrans0.ltrans.o] Error 1
make[3]: *** Waiting for unfinished jobs....
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[2]: *** [src/gromacs/CMakeFiles/libgromacs.dir/build.make:13411: lib/libgromacs.so.9.0.0] Error 1
make[1]: *** [CMakeFiles/Makefile2:4339: src/gromacs/CMakeFiles/libgromacs.dir/all] Error 2
make: *** [Makefile:166: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

I tried various modifications from the AUR page comments with no success.
I have a GeForce RTX 4050 with cuda 12.5.0-1 installed.

Would be happy for any help.

2

Hi!

Given that error is related to LTO, have you tried disabling it by adding !lto to the options array?

3

Thank you for the quick help.
Setting !lto seems to have solved the lto-wrapper error. I am now left with another issue:

[ 98%] Building CXX object src/gromacs/CMakeFiles/libgromacs.dir/selection/symrec.cpp.o
make[2]: *** No rule to make target 'src/external/build-fftw/fftwBuild-prefix/lib/libfftw3.a', needed by 'lib/libgromacs_d.so.9.0.0'.  Stop.
make[1]: *** [CMakeFiles/Makefile2:4322: src/gromacs/CMakeFiles/libgromacs.dir/all] Error 2
make: *** [Makefile:166: all] Error 2
==> ERROR: A failure occurred in package().
    Aborting...

So, that seems to be a problem with building fftw?

4

I pushed a new version that uses Arch’s fftw by default instead of building it. Can you retry installing?

1 Like
5

Hi vedran,

thank you very much!
I recompiled with the newest PKGBUILD (with DGMX_GPU=CUDA on) and everything finishes without errors.
Now, I can run all gmx commands just fine as long as I run completely on CPUs.
But as soon as I try using the RTX GPU, I get an error:

Command line:
  gmx mdrun -deffnm nvt -nb gpu -bonded gpu -pme gpu -update auto

1 GPU selected for this run.
Mapping of GPU IDs to the 2 GPU tasks in the 1 rank on this node:
  PP:0,PME:0
PP tasks will do (non-perturbed) short-ranged and most bonded interactions on the GPU
PP task will update and constrain coordinates on the CPU
PME tasks will do all aspects on the GPU
Using 1 MPI thread
Using 12 OpenMP threads 

/usr/lib/gcc/x86_64-pc-linux-gnu/13.3.0/include/c++/bits/unique_ptr.h:453: typename std::add_lvalue_reference<_Tp>::type std::unique_ptr<_Tp, _Dp>::operator*() const [with _Tp = DeviceStream; _Dp = std::default_delete<DeviceStream>; typename std::add_lvalue_reference<_Tp>::type = DeviceStream&]: Assertion 'get() != pointer()' failed.
Aborted (core dumped)

I guess this has nothing to do with the compilation of GROMACS, but rather some configuration of the GPU itself on my Arch setup?

6

Hi!

This is a known issue that sometimes appears with GCC13: Assertion failure in DeviceStreamManager for GPU codepaths when compiled with GCC 13. (#5087) · Issues · GROMACS / GROMACS · GitLab

Will be fixed in GROMACS 2024.3 (to be released later this month).