Martin Storsjö 529a79302b Reapply #2 of [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind ... This does mostly the same as D112126, but for the runtimes cmake files. Most of that is straightforward, but the interdependency between libcxx and libunwind is tricky: Libunwind is built at the same time as libcxx, but libunwind is not installed yet. LIBCXXABI_USE_LLVM_UNWINDER makes libcxx link directly against the just-built libunwind, but the compiler implicit -lunwind isn't found. This patch avoids that by adding --unwindlib=none if supported, if we are going to link explicitly against a newly built unwinder anyway. Since the previous attempt, this no longer uses llvm_enable_language_nolink (and thus doesn't set CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY during the compiler sanity checks). Setting CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY during compiler sanity checks makes cmake not learn about some aspects of the compiler, which can make further find_library or find_package fail. This caused OpenMP to not detect libelf and libffi, disabling some OpenMP target plugins. Instead, require the caller to set CMAKE_{C,CXX}_COMPILER_WORKS=YES when building in a configuration with an incomplete toolchain. Differential Revision: https://reviews.llvm.org/D113253		2021-12-09 21:38:14 +02:00
..
CMakeLists.txt	Reapply #2 of [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind	2021-12-09 21:38:14 +02:00
Components.cmake.in	…