Arch Linux User Repository

Propose to add hdf5 as a dependency for 2026.0, which ships with experimental support for a trajectory file format based on it. Should be picked up automatically by CMake without further configuration.

When compiling gromacs with cuda,please ensure to flatten your compilation options in /etc/makepackage.conf:

CFLAGS="-march=native -O2 -pipe -fno-plt -fexceptions \
        -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security \
        -fstack-clash-protection -fcf-protection \
        -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer"
CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS"

This will fail, put instead:

CFLAGS="-march=native -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer"
CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS"

@keyres: done, this is a good practice regardless.

I'd suggest adding a dependency to muparser, and building with -DGMX_USE_MUPARSER=EXTERNAL, otherwise there are needless conflicts with other packages.

Hi all, I have again problems compiling with cuda. I think it is still connected to compiling with gcc13. If I disable of linking time optimizations (!lto) I can successfully compile:

options=('!libtool' '!lto') 

I can also run the executables without the issues described in the comments below. Could someone confirm that this is not only a problem with my setup and the proposed solution is universal?

These are my makepkg.conf flags:

CFLAGS="-march=native -O2 -pipe -fno-plt -fexceptions \
        -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security \
        -fstack-clash-protection -fcf-protection \
        -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer"
CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS"

@e-kwsm You are right. I will push an update soon.

PKGBUILD:41:  cmake ../gromacs-v${pkgver}/ \
PKGBUILD:42:        -DCMAKE_INSTALL_PREFIX=/usr \
PKGBUILD:43:        -DCMAKE_INSTALL_LIBDIR=lib \
PKGBUILD:44:        -DGMX_DOUBLE=ON \
PKGBUILD:45:        #-DGMX_BUILD_OWN_FFTW=ON \
PKGBUILD:46:  # For AVX2 and AVX512 support, uncomment the previous line
PKGBUILD:47:        -DGMX_HWLOC=ON \
PKGBUILD:48:        -DREGRESSIONTEST_DOWNLOAD=ON

Here the command is malformed.

I was able to get the assertion failure to go away just by not defining _GLIBCXX_ASSERTIONS (while keeping _FORTIFY_SOURCE=3).

Addendum: $CXXFLAGS also needs to be reset:

export CXXFLAGS="$CFLAGS"

@dalima

I think you were lucky. I still got the same error when using CC=/opt/cuda/bin/gcc and CXX=/opt/bin/g++.

This isn't really surprising since those are actually just symlinks to /usr/bin/gcc-12 and /usr/bin/g++-12. Did you use makepkg or did you build the software by hand?

@hseara

The source of the problem seems to be in the default CFLAGS used by makepkg found in /etc/makepkg.conf. They are

CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
        -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security \
        -fstack-clash-protection -fcf-protection"

I was able to make the core dump go away by changing -D_FORTIFY_SOURCE=2 to -D_FORTIFY_SOURCE=1. The documentation for this macro says that level 2 introduces some run-time memory checks which might cause some otherwise well-behaved programs to fail; level 1 only does compile time checking.

I was able to get the package to build and run without the error by adding the following to the PKGBUILD just after the CC and CXX lines:

export CFLAGS="-mtune=native -O3 -pipe -fno-plt -fexceptions \
   -Wp,-D_FORTIFY_SOURCE=1 -Wformat -Werror=format-security \
   -fstack-clash-protection -fcf-protection"

(I dropped -march=x86-64 because the FFT library wouldn't compile properly with it. -mtune=native and -O3 resulted in a small performance boost during testing.)