CMake Error (missing OpenMP_CUDA_FLAGS) on Windows when building with CUDA

User discussions
1

GROMACS version: 2025.0
GROMACS modification: No

I’m trying to build GROMACS with CUDA support on Windows, using MSVC toolchain.

I have the latest CMake (3.31.5) installed.
I’ve setup CUDA 12.4.1, and I have Visual Studio 2022.
(in fact I’am using GitHub Actions Windows Runner, see this for more detail about installed packages)

The cmake command is

cmake .. "-DCMAKE_INSTALL_PREFIX=C:/GROMACS2025" "-DCMAKE_PREFIX_PATH=C:/FFTW;C:/OpenBLAS" "-DGMX_SIMD=AVX2_256" "-DGMX_GPU=CUDA" "-DGMX_HWLOC=ON" -G "Visual Studio 17 2022" -A "x64"

And it gave the following error message:

-- Performing Test HAVE_NO_DEPRECATED_COPY
-- Performing Test HAVE_NO_DEPRECATED_COPY - Failed
-- Performing Test HAS_WARNING_EVERYTHING
-- Performing Test HAS_WARNING_EVERYTHING - Failed
CMake Error at C:/Program Files/CMake/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:233 (message):
  Could NOT find OpenMP_CUDA (missing: OpenMP_CUDA_FLAGS
  OpenMP_CUDA_LIB_NAMES)
Call Stack (most recent call first):
  C:/Program Files/CMake/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:603 (_FPHSA_FAILURE_MESSAGE)
  C:/Program Files/CMake/share/cmake-3.31/Modules/FindOpenMP.cmake:616 (find_package_handle_standard_args)
  src/external/muparser/CMakeLists.txt:28 (find_package)


-- Configuring incomplete, errors occurred!

I’ve googled these, but find nothing about OpenMP_CUDA_FLAGS and OpenMP_CUDA_LIB_NAMES.

I’ve re-installed old cmake (like 3.30.7), the cmake command runs well (despite an error occurred during the subsequent compiling, but that error was not related to the problem in this post, so that error was discussed in a new post.).
Installing old version of cmake might be a work-around, but it is not a solution – new version of cmake will take place of old version eventually. So, I think this problem need a fix.

2

The error message you are encountering during the CMake configuration process indicates that the build system is unable to find the necessary OpenMP support for CUDA

3

Since cmake 3.30 works but cmake 3.31 doesn’t work, I think there must be some change between cmake 3.30 and 3.31.

For build system compatibility in future, I think the cmake files need improvements.

4

Hi,

CMake 3.31 added OpenMP::OpenMP_CUDA target, see FindOpenMP — CMake 3.31.8 Documentation, so I guess this change is what’s causing issues for you.

The error is suspicious since there should be no reason for OpenMP + CUDA to be broken. But our Windows build is not well-tested, and, to be honest, I won’t be surprised if handling of Windows + CUDA + OpenMP turns out to be buggy in CMake.

Good news is that we don’t really use OpenMP_CUDA target in GROMACS 2025.

Is the error still persists with newer version, can you try changing the offending line in src/external/muparser/CMakeLists.txt to find_package(OpenMP REQUIRED COMPONENTS CXX) so that OpenMP_CUDA is not even searched?

5

@al42and This modification works in CMake 3.31.6, which is in the latest (2025/9/19) GitHub Windows (Server 2025) CI.

For more information, you can check the CI log: github[.]com/KaneGreen/GROMACS-Windows-Builder/actions/runs/17846981845/job/50748095205
(Ignoring the last error, that’s CI networking error. GMX building process is finished successfully)

Thank you for your help.

I don’t know much about CMake and C++ related build systems. It would be great if this modification could be merged into future GMX versions without affecting building on other platforms (such as Linux).

1 Like
6

Thanks for confirming that it works!

I will try to get it into 2025.4 (and in the upstream muParser as well).

7

The fix got merged for 2025.4. Thanks again for reporting.

For future reference, that’s the config you’re using for testing, right? GROMACS-Windows-Builder/.github/workflows/build_cuda.yml at master · KaneGreen/GROMACS-Windows-Builder · GitHub

8

Yes, that is my build script for both testing and production.
I use the building products to run GMX on my Windows PC. (I also use native Linux builds on my Linux server)

1 Like
9

A similar problem appears to have occurred again in 2026.0.

I am building GROMACS 2026.0 CUDA version on Windows in GitHub Actions, using Visual Studio 2022 and CMake 3.31.

Here is the error message:

CMake Error at C:/Program Files/CMake/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:233 (message):
  Could NOT find OpenMP_CUDA (missing: OpenMP_CUDA_FLAGS
  OpenMP_CUDA_LIB_NAMES)
Call Stack (most recent call first):
  C:/Program Files/CMake/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:603 (_FPHSA_FAILURE_MESSAGE)
  C:/Program Files/CMake/share/cmake-3.31/Modules/FindOpenMP.cmake:616 (find_package_handle_standard_args)
  cmake/gmxManageCuda.cmake:156 (find_package)
  CMakeLists.txt:709 (include)

This code in cmake/gmxManageCuda.cmake didn’t exists in v2025.4, but was introduced in v2026-beta.

Beside, there is a warning before that error:

CMake Warning at C:/Program Files/CMake/share/cmake-3.31/Modules/CMakeDetermineCUDACompiler.cmake:15 (message):
  Visual Studio does not support specifying CUDAHOSTCXX or
  CMAKE_CUDA_HOST_COMPILER.  Using the C++ compiler provided by Visual
  Studio.
Call Stack (most recent call first):
  cmake/gmxManageCuda.cmake:90 (enable_language)
  CMakeLists.txt:709 (include)

See the full log here: github[.]com/KaneGreen/GROMACS-Windows-Builder/actions/runs/21513502027/job/61986095723

1 Like
10

Hi!

Thanks for the report!

The old workaround won’t work: in 2025.x, the problem was that we accidentally enabled OpenMP for CUDA; in 2026.0, it’s actually needed.

The root cause is a bug in CMake: Verifying connection...

Possible solutions (first one should be the least effort):

  • Use -DOpenMP_CUDA_FLAGS=-Xcompiler=-openmp -DOpenMP_CUDA_LIB_NAMES="" to explicitly tell CMake what to do (tested locally with CUDA 13.1, CMake 4.2, Visual Studio 2022 Community)
  • Use -G Ninja (tested indirectly via IDE integration; might need an explicit -DCMAKE_BUILD_TYPE=Release)
  • Wait for CMake 4.3.0, which promises to fix the bug (not tested)

Please confirm what works for you, we’ll update “Known issues”