ldionne added a comment. Re-reading this. the whole discussion about `filesystem` is now irrelevant, since it's part of the dylib.
The comment I have is that `libc++.dylib` is considered to be a system library on macOS, not a toolchain-provided library. This matters because we make sure that `/usr/lib/libc++.dylib` works well with the other system libraries it's built upon (such as `libSystem.dylib`) on a given release of macOS. For example, we make sure that the version of libc++ shipped on macOS 10.15 will work with the rest of the base system on macOS 10.15. If you're using trunk libc++ instead, there is no such guarantee. Now, I would argue this makes sense since you are using trunk libc++ -- you are probably not expecting a lot of guarantees. I believe one of the two following end-situations make sense, but anything in between is just weird: Solution 1: - Upstream Clang looks for headers in the toolchain and for the library in the toolchain. I think we should also make sure thusly built programs use the dylib in the toolchain, not the system one -- I guess setting `rpath` would achieve that? - AppleClang doesn't ship libc++ headers in the toolchain, and doesn't ship the dylib in the toolchain. Instead, those are found in the SDK (and in `/usr/lib` at runtime). This is already the case modulo a small caveat. - If someone wants to build an Upstream Clang toolchain that uses the system libc++, they can just omit the headers and the dylib from the toolchain, and it will fall back to the SDK ones. Solution 2: - Upstream Clang doesn't look for headers or dylib in the toolchain, **and we stop shipping those on Apple platforms with the LLVM release** cause that's just confusing. The SDK ones are always used, and you have to resort to compiler flags if you want to stray from that. - AppleClang becomes the same as Upstream Clang in that respect, i.e. it doesn't ship the headers or the dylib as part of the toolchain, and finds them in the SDK. Both of these solutions are self consistent. Solution (1) is more flexible, but you could end up with a libc++.dylib / headers that don't work on the specific system you're shipping to. For example, if you download the latest LLVM toolchain to an old macOS, your ToT `libc++.dylib` might need some symbols from `libSystem.dylib` that don't exist yet. Solution (2) is also self-consistent but less flexible. It has the advantage that you know the LLVM-built toolchain will always work fine on Apple platforms, cause it's using the system `libc++.dylib` and the headers from the SDK. IIUC, an accurate summary of the state we are currently in is: - Upstream Clang prefers the headers in the toolchain, but the library in the SDK. Yet, both the headers and the dylib are shipped alongside the toolchain. - AppleClang prefers the headers in the SDK, and the library in the SDK. (The headers are currently still shipped in the toolchain but they should be ignored if you have a sufficiently recent SDK that contains the headers -- this is transitional only). The current state of Upstream Clang is messed up. I personally think we should go with **Solution (1)** after double-checking with our linker folks that it's going to result in a reasonable Upstream LLVM toolchain. What do y'all think? Repository: rC Clang 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
