[PATCH] D34249: [libc++] Don't use UTIME_OMIT to detect utimensat on Apple

[Duncan P. N. Exon Smith via cfe-commits]

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 <reviews at 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
> 
> 
>