There are 2 CMake options for building OpenMP 1 via -DLLVM_ENABLE_PROJECTS=openmp and 2 -DLLVM_ENABLE_RUNTIMES=openmp When openmp is listed in both there are some CMake errors about duplicate targets. from this I assume we should do one or the other - project or runtime. What is the difference between a project and a runtime? Which one is preferred for openmp?
RUNTIMES! It needs a fresh Clang! The same holds true for libcxx, compiler-rt, and libunwind.
I.e. RUNTIMES first builds a fresh Clang and then builds the RUNTIMES projects. It you put openMP into PROJECTS, it might get build with an oldish gcc, which is not supported by OpenMP.
2 Likes
awesome, thanks!
The almost same question came up here, so I wonder if this is documented well enough?
https://libcxx.llvm.org/BuildingLibcxx.html#id4
libcxx calls it the bootstrapping build.
Or:
https://openmp.llvm.org/SupportAndFAQ.html
- How to build an OpenMP GPU offload capable compiler?[(Support, Getting Involved, and FAQ — LLVM/OpenMP 17.0.0git documentation)
"LLVM_ENABLE_RUNTIMES=”openmp”
Some great resources being shared here! thanks.
I got my build instructions here: Building LLVM with CMake — LLVM 17.0.0git documentation
which shows openmp under both project and runtime.
The same holds true for libcxx, compiler-rt, and libunwind.
False for host bootstrapping.
I suppose RUNTIMES build would be just for convenience.
Ideally, each PROJECTS build should check capabilities of the host compiler and should reject if the host compiler wasn’t capable. (OTOH RUNTIMES build may assume just-built clang should be able of building each RUNTIMES)
libcxx relies on a trunk version of Clang.
Even for OpenMP, the build of libomp and libomptarget are different. For libomp, project build uses the compiler to build LLVM, while runtime build uses the in-tree clang. For libomptarget, in-tree clang is always used.
It doesn’t mean that libcxx should be built with just-built clang in the same stage. I have pointed out the additional stage would be required for bootstrapping libcxx.