phosek added a comment. I agree with your analysis and I'd also prefer **Solution (1)**, I've rebased the change and included a simple test.
Right now, there's nothing specific to libc++, we're simply relying on the linker. Alternative would be to have a more explicit logic in DarwinClang::AddCXXStdlibLibArgs <https://github.com/llvm/llvm-project/blob/872633b28538f87a2b7f61bcb91259cf7e09dfa1/clang/lib/Driver/ToolChains/Darwin.cpp#L2120> akin to the existing logic for libstdc++ (which looks like a legacy code), but we would probably need a new flag to control whether to look for libc++ in the toolchain or fallback onto SDK. Regarding `rpath`, that particular aspect is problematic when you want to build relocatable binaries. Our strategy is to use static linking for libc++ to avoid this issue. That way we can guarantee that the binaries we produce with our toolchain always use libc++ version we want (which is consistent across all platforms we support). Since Darwin driver currently doesn't support the `-static-libstdc++` flag like other targets, we set `LDFLAGS=-nostdlib++ /path/to/clang/lib/libc++.a` on Darwin which works but I'd prefer if we could just use `-static-libstdc++` everywhere. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D45639/new/ https://reviews.llvm.org/D45639 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
