Reapply #2 of [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compile...
authorMartin Storsjö <martin@martin.st>
Sat, 23 Oct 2021 22:11:20 +0000 (01:11 +0300)
committerMartin Storsjö <martin@martin.st>
Thu, 9 Dec 2021 19:38:14 +0000 (21:38 +0200)
commit529a79302bf35f9a5822cc00395bba99f3575e30
treeb6e6036720d1cbdc470f0aba720d62b0fe29cb32
parenta9a14990809dbc4fb081ae0ae61f15c4a422b86c
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
libcxx/CMakeLists.txt
libcxx/cmake/config-ix.cmake
runtimes/CMakeLists.txt