phosek added a comment. In https://reviews.llvm.org/D45639#1193112, @ldionne wrote:
> @phosek I don't understand how you can expect code compiled with new headers > to link against an old dylib, unless you're setting the target platform, in > which case anything that would fail to link will instead be a compiler error. > I mean, we're adding stuff to the dylib from one version to the next, so _of > course_ it won't always work. @ldionne it's the other way round. Today, Clang driver on macOS automatically uses headers that are part of the compiler distribution (i.e. `-I../include/c++/v1`) but it always links against the system library (`/usr/lib/libc++.dylib`) because the library path to libraries that are shipped with the compiler (`-L../lib`) is never added to the link-line. Those two may not necessarily be the same version, and almost certainly won't be if you use Clang build from trunk. We hit this case again recently where developers are trying to use libc++ filesystem library. Using `#include <filesystem>` just works but `-lc++fs` fails because that library is not shipped as part of macOS at the moment, so developers need to add explicit `-L<path to compiler>/../lib` on macOS. This is not the case on other platforms such as Linux. The purpose of this patch is to make the driver behave more consistently across platforms so developers who build their own Clang don't need to explicitly pass `-L<path to compiler>/../lib` on macOS. 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
