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

[Idar Tollefsen via Phabricator via cfe-commits]

itollefsen added a comment.

This fails to account for whether you actually //have// the shared and/or 
static version of the library.




Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:1215
+else
+  CmdArgs.push_back("-l:libunwind.so");
 break;

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70416



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Idar Tollefsen via Phabricator via cfe-commits]

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 
 (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



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits