[PATCH] D70416: [Driver] Make -static-libgcc imply static libunwind

Fri Apr 24 01:02:17 PDT 2020

itollefsen added a comment.

I only build libunwind as a static library because it's (so far) the approach that gets me the furthest in avoiding all of the trouble that comes from having multiple libunwind (on Linux). I'm also running with the patch from D26244 <https://reviews.llvm.org/D26244> (now abandoned unfortunately).

This approach works quite well. It doesn't solve everything tough.

I can use the (default) static version of the sanitizer runtimes as long as the project being built doesn't itself use another libuwnind. If it does, I can use the shared sanitizer runtimes since they are linked against the static LLVM libunwind and therefore self-contained. Obviously, this only works for sanitiziers that //have// shared runtimes. Those that don't can't be used in this case. Well, as far as I've been able to work out at least.

I planned on experimenting with merging libunwind into the shared version of libc++abi (i.e. the whole libunwind archive) to see if that could solve it, but haven't gotten around to testing it yet.

================
Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:1215
+    else
+      CmdArgs.push_back("-l:libunwind.so");
     break;
----------------
saugustine wrote:
> itollefsen wrote:
> > If you are building with `-DLIBUNWIND_ENABLE_SHARED:OFF -DLIBUNWIND_ENABLE_STATIC:ON`, there's no shared version available. And vice versa. This doesn't account for that.
> Although true, I don't believe this is any different from the parallel libgcc situation. libgcc_eh is the static version, and will never be satisfied by the dynamic version. libgcc_s is the dynamic version, and can never satisfy the static version. See lines 1204-1208 above.
> 
> The case where you ask for a static compiler-rt but still want a dynamic unwind library is new. I'm not opposed to supporting it, but "what gcc does" isn't a terrible standard.
I haven't really requested anything specific one way or the other (I think).

I'm guessing `getLibGccType()` returns `LibGccType::SharedLibGcc` because `CCCIsCXX()` returns true.

Even if it returned `LibGccType::UnspecifiedLibGcc`, the shared version would still be used though.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70416/new/

https://reviews.llvm.org/D70416