apple: Make public mach API available on all Apple targets again

[valentynkit]

mach API declarations were gated to macOS only in e6bfb18 after mach_vm.h failed to build in the iOS tests, but mach_vm.h is the only one of these headers that is macOS only. The other declarations, mach_absolute_time, mach_timebase_info, mach_host_self, mach_thread_self and mach_task_self, are public on every Apple OS and were available up to libc 0.2.189, so gating them to macOS broke consumers that updated to 0.2.190, e.g. num_threads through time's local-offset feature.

This drops the macOS gate on them and includes their headers in the ctest for all Apple targets again. mach_vm_map stays macOS only.

More details of the missing declarations: #5601 (comment)

Alternative: it could be gated to any(target_os = "macos", target_os = "ios") instead, but the tvOS, watchOS and visionOS SDKs declare the same functions, so it seems more reasonable to have them on all Apple targets, as in 0.2.189.

This targets libc-0.2 because main no longer has these declarations (deprecated).

Addresses #5601

This PR only covers the declarations that #5606 doesn't cover, #5606 restores _dyld_image* and mach_header*. Happy to add those here if you'd prefer to cover this declarations in this PR also.

[rustbot]

⚠️ Warning ⚠️

• Pull requests are usually filed against the main branch for this repo, but this one is against libc-0.2. Please double check that you specified the right target!

[valentynkit]

I couldn't find iOS SDK headers online, so here's the way to check them in a local iOS SDK (Xcode 26.6, iOS 26.5) macOs device:

$ cd "$(xcrun --sdk iphoneos --show-sdk-path)/usr/include/mach"

Declared on iOS:

$ grep -n 'mach_absolute_time(void)\|mach_timebase_info(' mach_time.h
46:kern_return_t           mach_timebase_info(
53:uint64_t                        mach_absolute_time(void);

$ grep -n 'mach_host_self\|mach_thread_self\|mach_task_self_;' mach_init.h
74:extern mach_port_t mach_host_self(void);
75:extern mach_port_t mach_thread_self(void);
80:extern __swift_nonisolated_unsafe mach_port_t      mach_task_self_;

mach_vm.h is the only unsupported header:

$ grep -l '#error' *.h
mach_vm.h
$ head -1 mach_vm.h
#error mach_vm.h unsupported.

Same with appletvos, watchos or xros instead of iphoneos.

_dyld_image* and mach_header* (../mach-o/) could be checked the same way. #5606 covers those just for iOS.

[tgross35]

@madsmtm what are your thoughts?

[madsmtm]

Let me provide a bit of context: I think our support story for symbols should generally be "if it compiles in C (with the correct SDK and target) it should compile with libc".

That means that the problematic things are:

1. If the header/symbol is only available in the MacOSX.sdk, and not in the iPhoneOS.sdk / iPhoneSimulator.sdk / ...
2. If the item is marked with __XYZ_UNAVAILBLE or __XYZ_PROHIBITED (using it from C errors with 'my_function' is unavailable).

In both of these cases, cfg-gating the symbol away is the right thing to do, and I think that's roughly the rule I tried to follow in #5158 (which is why I believe that e.g. removing proc_pidinfo was the right thing to do).

Notably, this excludes whatever the whims of Apple's App Store Review are. E.g. we still expose the mach_absolute_time symbol, even though that will cause rejections from the App Store.

Hopefully that makes sense?

---

With that, I think that e6bfb18 was correct in removing mach_vm_map, since that symbol (and the whole mach/mach_vm.h header) is genuinely unavailable on iOS/tvOS/etc, and would fail to compile in C too. But the rest was probably wrong.

All of this a long-winded way of saying that I think this PR is correct.

View changes since this review

[nicoburns]

The bug that this PR fixes breaks the num_threads crate on iOS (which calls libc::mach_task_self). That is itself a dependency of time if the local-offset feature is enabled.

[tgross35]

Thank you!

View changes since this review

[tgross35]

The bug that this PR fixes breaks the num_threads crate on iOS (which calls libc::mach_task_self). That is itself a dependency of time if the local-offset feature is enabled.

Note that that crate is then relying on long-deprecated API, these warnings shouldn't be ignored. Or it's worth an issue if there is no good workaround.