CMake OpenMP target incompatible with Clang using MSVC and GNU CLI

[mmuetzel]

In the closed issue https://github.com/DrTimothyAldenDavis/SuiteSparse/issues/309, @chengts95 noted in the 30th comment:

Also, SuiteSparse_tic and SUITESPARSE_TIME are omp_get_wtime but suitesparse_config link to openmp with private flag, and it caused problems for Mongoose_Test_Reference because it was not linked to openmp libs for static libraries.

Opening a separate issue so that this won't get forgotten.

The build errors like the following:

[4/5605] Linking C shared library SuiteSparse_config\Release\suitesparseconfig.dll
FAILED: SuiteSparse_config/Release/suitesparseconfig.dll SuiteSparse_config/Release/suitesparseconfig.lib 
cmd.exe /C "cmd.exe /C ""C:\Program Files\CMake\bin\cmake.exe" -E __create_def D:\a\SuiteSparse\SuiteSparse\build\SuiteSparse_config\CMakeFiles\SuiteSparseConfig.dir\Release\exports.def D:\a\SuiteSparse\SuiteSparse\build\SuiteSparse_config\CMakeFiles\SuiteSparseConfig.dir\Release\exports.def.objs --nm="C:\Program Files\LLVM\bin\llvm-nm.exe" && cd D:\a\SuiteSparse\SuiteSparse\build" && C:\PROGRA~1\LLVM\bin\clang.exe -fuse-ld=lld-link -nostartfiles -nostdlib -O3 -DNDEBUG -Wno-extra-semi-stmt -Wno-extra-semi-stmt -D_DLL -D_MT -Xclang --dependent-lib=msvcrt  -Xlinker /DEF:SuiteSparse_config\CMakeFiles\SuiteSparseConfig.dir\Release\exports.def -shared -o SuiteSparse_config\Release\suitesparseconfig.dll  -Xlinker /MANIFEST:EMBED -Xlinker /implib:SuiteSparse_config\Release\suitesparseconfig.lib -Xlinker /pdb:SuiteSparse_config\Release\suitesparseconfig.pdb -Xlinker /version:7.7 SuiteSparse_config/CMakeFiles/SuiteSparseConfig.dir/Release/SuiteSparse_config.c.obj  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -loldnames  && cd ."
lld-link: error: undefined symbol: omp_get_wtime
>>> referenced by SuiteSparse_config/CMakeFiles/SuiteSparseConfig.dir/Release/SuiteSparse_config.c.obj:(SuiteSparse_tic)
>>> referenced by SuiteSparse_config/CMakeFiles/SuiteSparseConfig.dir/Release/SuiteSparse_config.c.obj:(SuiteSparse_toc)
>>> referenced by SuiteSparse_config/CMakeFiles/SuiteSparseConfig.dir/Release/SuiteSparse_config.c.obj:(SuiteSparse_time)
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The error probably occurs because the OpenMP libraries aren't set for some reason by FindOpenMP.cmake:

-- OpenMP C libraries:       
-- OpenMP C include:         
-- OpenMP C flags:          -fopenmp=libomp 

IIUC, they should be set to the same as when building with clang-cl:

-- OpenMP C libraries:      C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.37.32822/lib/x64/libomp.lib 
-- OpenMP C include:         
-- OpenMP C flags:          -Xclang -fopenmp 

[mmuetzel]

That is probably due to the same issue that is mentioned here: https://discourse.cmake.org/t/openmp-linking-errors-on-windows-using-ninja-and-clang/7246

If there is no open bug report about that for CMake yet, it might make sense to create one...

[mmuetzel]

A work-around for this issue until it is fixed in upstream CMake is to use clang-cl instead of clang and clang++ when targeting MSVC.

[DrTimothyAldenDavis]

Is this resolved now, by using clang-cl ?

[mmuetzel]

Using clang-cl works around this issue. The issue is still there with clang when building a msvc target. That issue probably needs to be fixed in upstream CMake.

It might be best to keep this open until this is fixed in case someone else runs into the same issue.

[mmuetzel]

See #760 for a reproducer in CI.

[mmuetzel]

I opened a merge request for CMake proposing the change from #760: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9235

[mmuetzel]

The change has been accepted upstream and should be part of CMake 3.29 when it will be released (unless it will be reverted for some reason before the release).

I don't know how often CMake is updated in MS Visual Studio. It is at cmake version 3.27.2-msvc1 for my Visual Studio 2022 installation. That version was tagged August 10, 2023. So, it might take a while before that fix finds its way into Visual Studio.

[mmuetzel]

CMake 3.29 (for which this should be fixed) has just been released: https://cmake.org/cmake/help/v3.29/release/3.29.html

I don't know how long it will take until that version finds its way into MS Visual Studio.