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

Petr Hosek via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 4 01:42:11 PDT 2023


petrhosek wrote:

> 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?)

I was thinking about always ignoring previously defined targets, regardless of the type, since I cannot think of a case where using a previously defined target in a check call would be desirable.

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


More information about the llvm-commits mailing list