[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

In https://reviews.llvm.org/D45639#1243010, @ldionne wrote:

> Sorry, my comment was wrong. You're right, using new libc++ headers and linking against an old `libc++.dylib` is a supported use case, and in fact this is exactly what happens whenever you use new libc++ headers and link against the system-provided `libc++.dylib` on macOS. However, what is _not_ supported is linking against a new `libc++.dylib` and then trying to run using the system's `libc++.dylib`, which may be older.
>
> If you add `-L<driver-path>/../lib`, will you start linking against the Clang-provided `libc++.dylib`? If so, and if you run the resulting application without setting the `DYLD_LIBRARY_PATH` to include the Clang-provided `libc++.dylib`, your program won't run because the system `libc++.dylib` may not include all symbols that the newer Clang-provided `libc++.dylib` contains.


Yes, that's an issue and not something this change deals with. The way we handle it in our build is statically linking libc++.

> Not shipping filesystem on macOS is a design choice we're making because the filesystem library is not ABI stable. Adding `-L<path-to-compiler>/../lib` explicitly shows that you understand you're doing something unusual (and not officially supported), which is good.
> 
> I assume this does not happen on Linux because Linux distributions must include `libc++fs.a` as part of their system -- is that really the case?

On Linux the driver always adds `-L<path-to-compiler>/../lib` so `libc++fs.a` is picked up whenever you pass `-lc++fs`.

> Thanks for the good explanation -- now I understand the purpose of the patch. However, I think we need a larger discussion around how libc++ is shipped to users and what use cases we want to support. For example, one question I have is why we're even shipping `libc++.dylib`, `libc++abi.dylib` and `libunwind.dylib` in our LLVM releases for MacOS, given they are provided by the system (and mixing them is a recipe for disaster). Another question is whether the LLVM-provided Clang should instead always link to the LLVM-provided libraries (which would require users setting the `DYLD_LIBRARY_PATH` properly to avoid falling back onto the macOS-provided `libc++.dylib`).
> 
> I'm quite sympathetic to your use case (and in fact we have similar use cases), but I'm uncomfortable moving forward with this patch until we have a better understanding of some important surrounding questions. I'd like to talk with @dexonsmith about it and then maybe we can meet at the LLVM Dev Meeting (if you plan to attend) with other libc++ people to flesh those questions out?

I'll be at LLVM Dev Meeting and I'd be happy to meet and discuss this.


Repository:
  rC Clang

https://reviews.llvm.org/D45639