[llvm-dev] building LLVM 11 with OpenMP on Windows

[Geoff Levner via llvm-dev]

I'm not sure this is the right place to post... If not, feel free to redirect me.

I am trying to build LLVM 11, including Clang and OpenMP, on a Windows machine with Visual Studio 2019 installed.

Clearly the openmp project is not adapted to a multiple configuration build system like Visual Studio. It assumes that library files are in a lib directory rather than in lib/Release, lib/Debug, etc. I have tried to build with LIBOMP_COPY_EXPORTS disabled, which helps, but I still get link errors.

So I have tried to build with nmake instead, which is a single configuration system like make. Strangely, this works for a release build, but not for a debug build. When I try to build in debug, I get error messages about unacceptable uses of std::atomic<unsigned int>.

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...

Has anybody out there managed to solve this problem one way or another?

Geoff

[Michael Kruse via llvm-dev]

Am Di., 3. Aug. 2021 um 05:05 Uhr schrieb Geoff Levner via llvm-dev
<llvm...@lists.llvm.org>:

> 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...

You could use ninja on Windows (-cmake GNinja) which only has a single
configuration per builddir. If compilation with cl.exe fail, try
LLVM_ENABLE_RUMTIMES=openmp (instead of LLVM_ENABLE_PROJECTS=openmp)
which will build libomp using just-built clang.

Michael
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[Geoff Levner via llvm-dev]

Thanks for that, Michael.

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.

(Also nmake is very, very slow. Presumably ninja will be faster.)

[Geoff Levner via llvm-dev]

I tried setting LLVM_ENABLE_RUNTIMES=openmp instead of LLVM_ENABLE_PROJECTS=openmp. The error messages are different, but the errors result all the same. So for now I will have to continue commenting out KMP_DEBUG and the faulty trace commands that result when compiling in debug. Unless somebody else has a suggestion?

Ninja is much faster than nmake, though.

[Michael Kruse via llvm-dev]

Am Di., 3. Aug. 2021 um 15:29 Uhr schrieb Geoff Levner <gle...@gmail.com>:
> I tried setting LLVM_ENABLE_RUNTIMES=openmp instead of LLVM_ENABLE_PROJECTS=openmp. The error messages are different, but the errors result all the same. So for now I will have to continue commenting out KMP_DEBUG and the faulty trace commands that result when compiling in debug. Unless somebody else has a suggestion?

Consider opening a bug report that includes the cmake options you are
using and the errors you are getting, maybe even upload a patch to
make compilation work to reviews.llvm.org.

[Geoff Levner via llvm-dev]

OK, I've opened two bug reports:

https://bugs.llvm.org/show_bug.cgi?id=51375

https://bugs.llvm.org/show_bug.cgi?id=51380

Geoff