Project

General

Profile

Bug #2927

CMake 3.14.1 fails to properly run gmxDetectCpu.make

Added by Victor Rusu 8 months ago. Updated about 17 hours ago.

Status:
Feedback wanted
Priority:
Low
Assignee:
-
Category:
build system
Target version:
Affected version - extra info:
2019.1
Affected version:
Difficulty:
simple
Close

Description

CMake is not able to compile cpuinfo.cpp when compiling GROMACS 2019.1 on Piz Daint (Cray system) with CMake version 3.14.1.

The reported error is

-- Did not detect build CPU vendor - detection program did not compile

The reason is a wrong placement of quotes by CMake. Note the opening of the quotes on the variable GMX_X86_GCC_INLINE_ASM and the closing just after the variable GMX_TARGET_X86.

/opt/cray/pe/craype/2.5.18/bin/CC  -DGMX_X86_GCC_INLINE_ASM="1 -I/tmp/gpu/GROMACS/2019.1/CrayGNU-19.03/gromacs-2019.1/src -DGMX_CPUINFO_STANDALONE  -DGMX_TARGET_X86=1"  -O3 -fno-math-errno -fopenmp -fPIC -std=c++11      -o CMakeFiles/cmTC_75cb9.dir/cpuinfo.cpp.o -c /tmp/gpu/GROMACS/2019.1/CrayGNU-19.03/gromacs-2019.1/src/gromacs/hardware/cpuinfo.cpp
/tmp/gpu/GROMACS/2019.1/CrayGNU-19.03/gromacs-2019.1/src/gromacs/hardware/cpuinfo.cpp:60:14: fatal error: gmxpre.h: No such file or directory
 #    include "gmxpre.h" 
              ^~~~~~~~~~
compilation terminated.

Older version of CMake generate the quote placement.

Alternatives are to use an older version of CMake. Or to set the GMX_SIMD flag manually.
Or
Remove the quotes on the definition of the _compile_definitions variable inside the cmake/gmxDetectCpu.cmake file.
Which means, change from

set(_compile_definitions "${GCC_INLINE_ASM_DEFINE} -I${PROJECT_SOURCE_DIR}/src -DGMX_CPUINFO_STANDALONE ${GMX_STDLIB_CXX_FLAGS} -DGMX_TARGET_X86=${GMX_TARGET_X86_VALUE}")

to
set(_compile_definitions ${GCC_INLINE_ASM_DEFINE} -I${PROJECT_SOURCE_DIR}/src -DGMX_CPUINFO_STANDALONE ${GMX_STDLIB_CXX_FLAGS} -DGMX_TARGET_X86=${GMX_TARGET_X86_VALUE})

History

#1 Updated by Szilárd Páll 8 months ago

  • Target version set to 2019.3

#2 Updated by Szilárd Páll 8 months ago

Sounds like a cmake bug, have you filed a report with cmake?

#3 Updated by Paul Bauer 6 months ago

Hello, any updates on if this is a CMake bug?

#4 Updated by Paul Bauer 6 months ago

  • Status changed from New to Feedback wanted
  • Target version changed from 2019.3 to 2019.4

#5 Updated by Victor Rusu 6 months ago

Paul Bauer wrote:

Hello, any updates on if this is a CMake bug?

Dear Paul, I checked newer versions of CMake, for me the issue is gone. So, I think we can close the issue.

#6 Updated by Yoshitaka Moriwaki 6 months ago

Hi,

This issue still occurs when compiling GROMACS 2019.3 with CMake 3.14.5 on macOS Mojave 10.14.5. With the hack for cmake/gmxDetectCpu.cmake, CPU detection worked correctly.

#7 Updated by Szilárd Páll 5 months ago

Victor Rusu wrote:

Paul Bauer wrote:

Hello, any updates on if this is a CMake bug?

Dear Paul, I checked newer versions of CMake, for me the issue is gone. So, I think we can close the issue.

Which newer version did you check, can you please let us know?

If 3.14.5 still has the issue, than there is a problem to solve.

#8 Updated by Ricardo Silva 4 months ago

Hello,

We have found the same issue in our builds and would like to contribute with a couple of datapoints:

We are building gromacs 2019.2 and see this issue with both cmake 3.14.4 and 3.15.1.

Patching the cmake/gmxDetectCpu.cmake file as mentioned above solves the issue with both versions.

Let me know if I can provide any other information that might help.

#9 Updated by Paul Bauer 2 months ago

  • Target version changed from 2019.4 to 2019.5

no fix in sight for 2019.4

#11 Updated by Ricardo Silva 25 days ago

Hello,
We actually found that the patch we had is no longer necessary for 2019.4 as there seems to have been some work done in the CPU detection cmake files which make not necessary any more. (And I suspect Christoph Junghans found the same as he committed the corresponding change on the Spack repo.)

In short, it needs verification, but I think this was actually solved in the 2019.4.

#12 Updated by Paul Bauer about 17 hours ago

hello, can you confirm that this is fixed since 2019.4? Then I can close the issue here

Also available in: Atom PDF