[libcxx] [libcxxabi] [libunwind] [llvm] [runtimes] remove workaround for old CMake when setting `--unwindlib=none` (PR #93429)

[Martin Storsjö via cfe-commits]

mstorsjo wrote:

> So I've been trying to follow down the rabbit hole of the failing flag checks, and it seems the combination of `CXX_SUPPORTS_UNWINDLIB_EQ_NONE_FLAG` plus https://gitlab.kitware.com/cmake/cmake/-/issues/23454 has a wider blast radius than anticipated.
> 
> I'm not claiming that adding the `_previous_CMAKE_{REQUIRED_LINK_OPTIONS,TRY_COMPILE_TARGET_TYPE}` dance everywhere is the right approach here, but it was - so far - the obvious path to just try to get things green again. It's conceivable though that it would be easier to simply shift the detection of `CXX_SUPPORTS_UNWINDLIB_EQ_NONE_FLAG` until after the other flag checks have been performed? 🤔

That's probably not possible...

The point is that when bootstrapping a new sysroot from scratch (i.e. building the initial libunwind etc), in a configuration where libunwind is linked in automatically, every test that tries to do linking will fail (as it implicitly tries to link in libunwind, which does not exist yet). Therefore, we need to add `--unwindlib=none` as an additional linker flag, as soon as possible, so that all following cmake checks will get the right result.

Also, in general, setting `CMAKE_TRY_COMPILE_TARGET_TYPE` to `STATIC_LIBRARY` in too wide a context will also give false positive checks, for cases where we intentionally want to check whether linking some library works and is found. But perhaps the way you do it here, adding it in a narrow context only when doing specific checks, is the right way? I'm not sure...

So that cmake issue seems to be really, really unfortunate here. :-( I wonder if the cure is worse than the disease here - and if it would be better to just keep what we have now - and simplify it only if cmake adds something like `CMAKE_REQUIRED_DYNAMIC_LINK_OPTIONS` or so.

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