# OpenMP linking errors on Windows using Ninja and clang

**URL:** https://discourse.cmake.org/t/openmp-linking-errors-on-windows-using-ninja-and-clang/7246
**Category:** Usage
**Tags:** os:windows, comp:clang, gen:ninja
**Created:** [January 14, 2023, 11:29pm UTC](https://discourse.cmake.org/t/openmp-linking-errors-on-windows-using-ninja-and-clang/7246 "2023-01-14T23:29:37Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![KrisThielemans](https://discourse.cmake.org/user_avatar/discourse.cmake.org/kristhielemans/32/532_2.png) [@KrisThielemans](https://discourse.cmake.org/u/KrisThielemans)
#### Post date: [January 14, 2023, 11:29pm UTC](https://discourse.cmake.org/t/openmp-linking-errors-on-windows-using-ninja-and-clang/7246/1 "2023-01-14T23:29:37Z")

</div>

In our project we use OpenMP successfully in many systems, including Windows with VS compiler (and I believe both VS generator and Ninja). Relevant lines are essentially

```cmake
target_link_libraries(buildblock OpenMP::OpenMP_CXX)
add_executable(bla buildblock)

```

However, I am now trying to use Ninja on AppVeyor which seems to then select CLang as compiler. Should work…

Unfortunately, I get linking errors like this

```auto
lld-link: error: undefined symbol: __kmpc_dispatch_init_8
...
lld-link: error: undefined symbol: omp_get_num_threads

```

Cutting various ugly bits in the log shows that no openmp flag nor library is added for linking:

```auto
C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE -fuse-ld=lld-link -nostartfiles -nostdlib -Wno-undefined-var-template -O3 -DNDEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrt src/utilities/CMakeFiles/list_detector_and_bin_info.dir/list_detector_and_bin_info.cxx.obj <cut> 
 src/buildblock/buildblock.lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -loldnames"

```

More details and full log file are at  
[OpenMP linking errors on Windows using Ninja and clang · Issue #1129 · UCL/STIR (github.com)](https://github.com/UCL/STIR/issues/1129)

I did a search on the CMake issues and found an issue where the `fopenmp` linker flag is mentioned:  
[OpenMP with clang links to system libomp.so or drops rpath, when clang in non-standard location. (#21787) · Issues · CMake / CMake · GitLab (kitware.com)](https://gitlab.kitware.com/cmake/cmake/-/issues/21787)

Is this a CMake bug, or a bug in our code somewhere (I should probably add the openmp dependency on more of our libraries)? If the former, is there a workaround?

thanks for your help!  
kris

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [January 15, 2023, 2:45am UTC](https://discourse.cmake.org/t/openmp-linking-errors-on-windows-using-ninja-and-clang/7246/2 "2023-01-15T02:45:46Z")

</div>

It’s probably an issue with the `FindOpenMP` module. It probably just hasn’t had Clang on Windows support considered properly.

---

<div class="post-metadata">

### Author: ![etiennemlb](https://discourse.cmake.org/user_avatar/discourse.cmake.org/etiennemlb/32/3147_2.png) [@etiennemlb](https://discourse.cmake.org/u/etiennemlb)
#### Post date: [February 19, 2024, 1:29pm UTC](https://discourse.cmake.org/t/openmp-linking-errors-on-windows-using-ninja-and-clang/7246/3 "2024-02-19T13:29:55Z")

</div>

There is a problem with FindOpenMP not being able to find the libraries used at link time when the `-fopenmp=libomp` is given to the clang/clang++ driver. On linux boxes it generally use the `-v` flags to dump all the implicit libraries (including openmp). This trick seems broken on Windows.

You can use something like (or more target oriented) that to workaround the issue:  
`-DCMAKE_EXE_LINKER_FLAGS="-fopenmp"`