[PATCH] D96070: [clang] [driver] Enable static linking to libc++

[Louis Dionne via Phabricator via cfe-commits]

ldionne added a comment.

I think the root cause of the push back you're getting is that this is normally handled by vendors when they decide how they're going to ship libc++ on their platform or in their toolchain.

For example, on Apple platforms, we ship `libc++.dylib`, and we make sure to re-export `libc++abi.dylib`'s symbols from `libc++.dylib`. The result is that you only need to specify `-lc++` (which the compiler does by default), and everything "works". Since we don't ship `libc++.a`, there's no out-of-the-box solution to make it work - it's not officially supported. Some folks do diverge from that, however we assume they are willing to get their hands dirty and use the flags required to make it work (i.e. `-lc++ -lc++abi`). My understanding is that the same goes for other platforms, where each has their preferred way of shipping libc++. If we were to officially ship `libc++.a` in the SDKs for Apple platforms, I could imagine that we'd want to merge `libc++abi.a` into `libc++.a`, and there again you'd only need to specify `-static -lc++` and everything would work (unless I'm missing something).

Making that work out-of-the-box would be something we'd want to achieve in how we're building and shipping libc++, not by modifying the behaviour of the Clang driver on multiple platforms.

In D96070#2544297 <https://reviews.llvm.org/D96070#2544297>, @tbaeder wrote:

> [...]
>
> Or should clang just not do anything here and people should be aware they need to pass additional flags when using libc++ (on Linux)?

The TL;DR of what I wrote above is that I believe this is the correct answer. My main area is Apple platforms and not Linux, though, so this is just my .02 as someone who ships libc++.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96070