For MinGW targets, we distinguish between an explicitly shared unwinder
library (requested via -shared-libgcc), an explicitly static one
(requested via -static-libgcc or -static) and the default case (which
just passes -lunwind to the linker, which will pick either shared or
static depending on what's available, with the normal linker logic).
This makes the implicit default case (as added in D79995) actually work as
it was intended, when using the g++ driver (which is the main usecase for
libunwind as far as I know).
Differential Revision: https://reviews.llvm.org/D98023
In the GNU toolchain, `-static-libgcc` implies that the unwindlib will
be linked statically. However, when `--unwindlib=libunwind`, this flag is
ignored, and a bare `-lunwind` is added to the linker args. Unfortunately,
this means that if both `libunwind.so`, and `libunwind.a` are present
in the library path, `libunwind.so` will be chosen in all cases where
`-static` is not set.
This change makes `-static-libgcc` affect the `-l` flag produced by
`--unwindlib=libunwind`. After this patch, providing
`-static-libgcc --unwindlib=libunwind` will cause the driver to explicitly
emit `-l:libunwind.a` to statically link libunwind. For all other cases
it will emit `-l:libunwind.so` matching current behavior with a more
explicit link line.
https://reviews.llvm.org/D70416
"clang++ hello.cc --rtlib=compiler-rt"
now can works without specifying additional unwind or exception
handling libraries.
This reworked version of the feature no longer modifies today's default
unwind library for compiler-rt: which is nothing. Rather, a user
can specify -DCLANG_DEFAULT_UNWINDLIB=libunwind when configuring
the compiler.
This should address the issues from the previous version.
Update tests for new --unwindlib semantics.
Differential Revision: https://reviews.llvm.org/D59109
llvm-svn: 356508
Petr Hosek