<div dir="ltr"><div>Thanks for that, Michael.</div><div><br></div><div>The workaround I have found for now is to use nmake and to avoid trace statements in OpenMP, which cause the compilation errors in the debug configuration, by commenting out the line in the OpenMP source code that #defines KMP_DEBUG to 1. But that is not a nice workaround. I will try setting LLVM_ENABLE_RUNTIMES, as you suggest, to see if that works without hacking the source code.</div><div><br></div><div>(Also nmake is very, very slow. Presumably ninja will be faster.)</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 3, 2021 at 5:22 PM Michael Kruse <<a href="mailto:llvmdev@meinersbur.de">llvmdev@meinersbur.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am Di., 3. Aug. 2021 um 05:05 Uhr schrieb Geoff Levner via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>:<br>
> Perhaps a solution would be to compile LLVM/Clang and OpenMP with Visual Studio but separately? Only I don't know how to do that...<br>
<br>
You could use ninja on Windows (-cmake GNinja) which only has a single<br>
configuration per builddir. If compilation with cl.exe fail, try<br>
LLVM_ENABLE_RUMTIMES=openmp (instead of LLVM_ENABLE_PROJECTS=openmp)<br>
which will build libomp using just-built clang.<br>
<br>
Michael<br>
</blockquote></div>