libc: update macOS headers to macOS 12.0 Monterey

[emidoots]

updates libc headers for macos to reflect the latest version present on macOS 12 Monterey

This is the result of running the following after ziglang/fetch-them-macos-headers#15:

rm -rf lib/libc/include/any-macos-any lib/libc/include/x86_64-macos-gnu lib/libc/include/aarch64-macos-gnu
fetch_them_macos_headers generate

Fixes #10200

Signed-off-by: Stephen Gutekanst stephen@hexops.com

[emidoots]

Although I am confident this PR does what it describes, I wanted to call out a question: is this the right solution?

#10200 makes a clear case for why we need the latest macOS libc headers (without them, we cannot link frameworks from the latest macOS SDK when cross compiling, only when building natively as Zig uses the system libc in that case I think)

At the same time Andrew makes a case in this issue for why we should only use the minimum supported macOS version's headers.

A different solution might be to say something like this:

If you intend to provide a Framework for Zig to compile, it must either be compatible with the lowest macOS version supported by Zig OR you must also provide the macOS SDK version you wish to target

[emidoots]

I believe I no longer need this change for my work, I can stick on the older version of the macOS SDK I believe, so we can defer making a decision here.

---

I think the issue is still valid and worth figuring out, however. I see these potential paths forward:

1. Do nothing: ship the lowest-supported macOS version headers (and framework stubs in the future). By doing this, using some newer frameworks when cross compiling is not possible.
   • For example, it would not be possible to use SharePlay/GroupActivities (added in macOS 12), or new Metal/CreateML features, when cross-compiling.
   • One particularly nasty problem here is answering "what is the lowest-supported macOS version"? I think ideally we track what has most market share, but there are no public numbers on this that seem reliable / up-to-date anywhere.
   • Another problem with this is that macOS tends to lag behind iOS/iPadOS/etc, and we must tie all of these together.
2. Ship the absolute latest macOS version.
   • The upside here is you can always use the latest APIs/frameworks.
   • We don't have to decide which minimum version to support.
   • In theory, due to dynamic linking against frameworks, as long as you do not use newer macOS APIs then binaries produced with the latest SDK will run on older macOS/iOS/etc versions I believe.
3. Ship every supported version, allow users to choose
   • The worst option IMO. Increased complexity on the Zig side.
   • Would still need to decide which version to default to.
   • Users would need to pick versions, some libraries would support only older versions while others would support only latest.
4. Middle-ground solution, mix and match SDK versions?
   • By default, Zig ships lowest-supported macOS version like we do today and targets that. This ensures all Zig libs in the ecosystem target that version by default.
   • Zig libs that need a newer macOS SDK version can supply the macOS SDK for cross-compilation. That SDK would be used for compiling that Zig library only, including using it for libc headers. Unlike setting b.sysroot which would try to use that SDK for compilation of all Zig libraries, this would occur for that single Zig library only.

[kubkon]

Thanks for the PR and issue @slimsag. I am fine with trying to keep macOS libc headers at the latest version given that Apple encourages their users to update their OSes to the latest possible version every year. That said, this means the libc headers we ship will be incompatible with anything but the latest sysroot (well, they might work with the previous sets but we can never guarantee that I guess?). I think I am still fine with that personally. Also, if anyone would like to target an older version of macOS from a foreign host they'd just need to provide the entire sysroot including the libc headers (which are part of every macOS SDK anyhow). Finally, as you already pointed out, targeting the latest macOS version is the simplest thing to maintain on our side too.

I'd like to hear @andrewrk's opinion on this before committing to any one particular strategy.

[kubkon]

Oh and also, sticking to the latest libc headers would go hand-in-hand in us tracking the latest LLVM release I guess.

[emidoots]

Conversation shifted to over here: ziglang/fetch-them-macos-headers#15 (comment)

[kubkon]

Superseded by #10215, closing.