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