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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
