[compiler-rt] Reapply [compiler-rt] Check for and use -lunwind when linking with -nodefaultlibs (PR #66584)

[Martin Storsjö via llvm-commits]

mstorsjo wrote:

 With the following:
> 
> ```
> cmake_minimum_required(VERSION 3.13.4)
> project(Test LANGUAGES CXX)
> add_library(unwind_static STATIC unwind.cpp)
> add_custom_target(unwind DEPENDS unwind_static)
> include(CheckLibraryExists)
> check_library_exists(unwind _Unwind_RaiseException "" COMPILER_RT_HAS_LIBUNWIND)
> ```
> 
> I get the same error:
> 
> ```
> CMake Error at cmake/linux-x64/share/cmake-3.25/Modules/CheckLibraryExists.cmake:71 (try_compile):
>   Only libraries may be used as try_compile or try_run IMPORTED
>   LINK_LIBRARIES.  Got unwind of type UTILITY.
> Call Stack (most recent call first):
>   CMakeLists.txt:9 (check_library_exists)
> ```
> 
> However, with the following:
> 
> ```
> cmake_minimum_required(VERSION 3.13.4)
> project(Test LANGUAGES CXX)
> add_library(unwind STATIC unwind.cpp)
> include(CheckLibraryExists)
> check_library_exists(unwind _Unwind_RaiseException "" COMPILER_RT_HAS_LIBUNWIND)
> ```
> 
> CMake fails to find `libunwind`:
> 
> ```
> /usr/bin/ld: cannot find -lunwind: No such file or directory
> ```
> 
> To me this really looks like a bug in CMake since the behavior is inconsistent. Specifically, I don't think CMake should consider the previously defined targets when performing checks regardless of their type.

Hmm, maybe. But even if CMake would be fixed to make the former case behave like the latter, what happens in the end when we link the component that we're building, and linking it against `unwind` (assuming the `check_library_exists` did succeed)? We're expecting this to inject a `-lunwind` to link against the toolchain's existing libunwind, but wouldn't it end up linking against the just-built libunwind? I guess that's not bad in itself, but not quite what was intended. If the cmake target `unwind` is a static or shared library, that would kinda work - but as it is a `UTILITY`, what would happen? (I guess that's what's happening within `check_library_exists` in some form?)

> Perhaps we should file an issue against CMake and include a link in the comment?

I guess we could - but given the above, I'm not quite sure what we'd do differently here even in the future if we can assume a baseline CMake with this issue fixed. If `TARGET unwind` exists, but is an internal utility target, not an actual shared/static library, we kinda can't link against it anyway?

https://github.com/llvm/llvm-project/pull/66584