Using runtime availability checking doesn't make sense for a system Libc++, as you point out. If we add runtime checks they ought to be non-default, and hidden behind configuration flags.
Also, do I remember correctly that __builtin_available requires linking against Foundation (and thus the Obj-C runtime) for NSProcessInfo, or has that dependency been removed/avoided? It would be surprising for the C++ standard library to pull in the Objective-C runtime. A reasonable configuration option, but not a reasonable default behaviour IMO. > On Feb 1, 2018, at 05:52, Nico Weber via Phabricator > <revi...@reviews.llvm.org> wrote: > > thakis added a comment. > > The powers that be updated the SDK on the chromium clang bots, so we need > some solution for this issue soon. > > The approach in this patch should work, but it seems conservative. Now libc++ > only uses utimesat() if it's built with a deployment target of macOS 10.13. > But if we were to set a deployment target of 10.12 and then _run_ on 10.13, > we could use utimesat() as well, even though this patch currently doesn't. > (Apple bundles libc++ with the system, so it's not a meaningful difference > for Apple-built libc++'s, but applications can build libc++ themselves and > statically link to it, and for those it would make a difference.) > > https://clang.llvm.org/docs/LanguageExtensions.html#objective-c-available has > some words on it (except that `@available` is spelled `__builtin_available` > in non-Objective-C code) -- thoughts on using runtime detection of utimes() > instead? That's how things are supposed to work on the Apple platforms. > > > https://reviews.llvm.org/D34249 > > > _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
