Created attachment 246388 [details] CMake core dump I am using 14.0-RELEASE FreeBSD 14.0-RELEASE #0 releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 05:57:23 UTC 2023 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERICamd64 1400097 1400097, but this issue also affected BETAs, RCs and IIRC 13.2-RELEASE. I am configuring GROMACS 2023.3 from [1] with CMake 3.26.1_3, compiler set to GCC 12.2.0_6 and OpenMPI 4.1.5_1 present on the system, using the command: % cmake -D CMAKE_C_COMPILER=gcc12 -D CMAKE_CXX_COMPILER=g++12 -S . -B build This will cause CMake to dump core. I verified that this does not happen when GCC is replaced with Clang (from the base system) or when OpenMPI is replaced MPICH 3.4.3_2. While I believe this is an issue with CMake, I found out that it did not happen in GROMACS 2021 so I bisected the issue one the GROMACS side. The offending commit [2] could be helpful to minimize the example CMakeLists.txt if that becomes necessary. Finally, I wondered if this is an issue with CMake or an issue with the build of CMake from Ports. I uninstalled CMake via pkg and used (via Linuxilator) the official Linux amd64 binary at the exact same version, downloaded from [3]. There is no core dump. Hope this helps. Let me know if I can provide more info. [1] https://manual.gromacs.org/2023.3/download.html [2] https://gitlab.com/gromacs/gromacs/-/commit/9088f06a56c6122f21a47e3f06509ce1737465ef [3] https://github.com/Kitware/CMake/releases/download/v3.26.1/cmake-3.26.1-linux-x86_64.tar.gz
This still occurs with CMake 3.27.7 installed via pkg.
Vedran, you might want to remove the core dump -- it contains some paths and SSH details that you might not want to share. IPv4 addresses, nothing too personal, though. From the name of the executable, and the size of the core, and strings in the core like `/home/vedranm/gaseri/dev/gromacs/build/CMakeFiles/CMakeScratch/TryCompile-VecQz7/cmTC_ed0ef` I'm going to conclude that this is not actually **cmake** segfaulting, but one of the programs that it builds during CMake-time. This is, to some extent, expected: CMake tries all kinds of stuff during configure, and some of those tests crash. Does the CMake step complete successfully? That's the important thing, not if there's a core from along the way. I can't immediately reproduce this locally, either: in a 13.2 poudriere environment, where I built OpenMPI 4 and fftw3 from ports (with clang, I suppose) and gcc13 (different from your experiment!) then gromacs can be configured. I needed an extra flag for CMake because fftw was not found -- possibly a mismatch because of compilers. Forcing it to use the slow bundled fftw got it through the CMake step and allowed building gromacs. I think we need a much more detailed reproduction scenario (one that starts with "Install 14-RELEASE, then pkg install gcc12 cmake, ...") to investigate further, but like I said: I think this is not actually a problem.
I don't think I have seen this happen with OpenMPI 5 so I wouldn't consider it an issue anymore. Regarding core dump, I agree, but I don't have privileges to remove it or mark it private. If you can do that, please do.