https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275168
Adriaan de Groot <adr...@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|New |In Progress
CC| |adr...@freebsd.org
--- Comment #2 from Adriaan de Groot <adr...@freebsd.org> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
