ldionne added a comment. In https://reviews.llvm.org/D45639#1243017, @kristina wrote:
> I think on Darwin it would **not** make sense to have `libc++fs.a` ship in > `libc++.dylib` especially considering that it ends up in the dyld cache and > that has a lot of other implications. It would make sense to ship it as a > separate library, perhaps as part of the SDK, at least for now. Indeed, this makes a lot of sense and this is exactly what I was thinking about. I'd like to get a more holistic plan before we do that though. > As far as making it a system dylib, it's a possibility as long as no core os > components depend on it and it's there solely for consumers. We can't do that unless that dylib is ABI-stable. Otherwise, imagine what happens when we update the OS (which would then contain a new version of that dylib): all consumers that link against that dylib will now crash at runtime because we'll have broken its ABI. 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
