| 24 Oct 2025 |
 emily | my point is that the xnu headers we use have a fundamentally different expectation for SPI_* than the source releases we build | 01:55:27 |
| emily | because of the two existing in different contexts | 01:55:33 |
| emily | if we make it expand to a real availability annotation in one, it's wrong for the other | 01:55:48 |
 Randy Eckenrode | We would use the SDK’s stubs, which means we want functioning checks for private symbols. | 01:56:13 |
| emily | right | 01:56:26 |
| emily | but only for XNU headers because we are not building our own XNU | 01:56:34 |
| emily | not for anything else we actually build | 01:56:40 |
| emily | despite those things sometimes using XNU headers | 01:56:47 |
| emily | given the divergence here, there's no way out of patching the XNU headers, because you want two different meanings for the same expression in different contexts | 01:57:02 |
| emily | Apple doesn't do what we do, so they don't run into the inconsistency | 01:57:20 |
| Randy Eckenrode | We would in fact want those to have functioning checks too because they are using private APIs that may not be available on our deployment target. | 01:57:44 |
| emily | "those" as in the source releases we build? | 01:58:14 |
| emily | did you look at the examples I linked? :( | 01:58:29 |
| emily | it's stuff defining those symbols | 01:58:37 |
| Randy Eckenrode | Yes. I had to add an availability check to one of the releases. | 01:58:38 |
| emily | that's different | 01:58:50 |
| emily | that's an API_* check | 01:58:54 |
| emily | and not something in a source release defining its own symbol | 01:59:01 |
| Randy Eckenrode | IIRC we don’t install the private headers for libpcap or libffi. How the symbols are defined for them doesn’t matter. | 01:59:51 |
| Randy Eckenrode | If we do, then we should strip out the checks. I do agree with that. | 02:00:28 |
| emily | dyld is a much more relevant example | 02:01:26 |
| Randy Eckenrode | How? It doesn’t install any headers. The only dylib it installs is libdsc_extractor.dylib, which doesn’t have any public API. | 02:02:42 |
| emily | substituteInPlace include/mach-o/utils_priv.h \
--replace-fail 'SPI_AVAILABLE(macos(15.0), ios(18.0), tvos(18.0), watchos(11.0))' ""
we do this. if we did not do this, it would start failing to build due to availability errors
| 02:03:39 |
| emily | incorrectly | 02:03:43 |
| Randy Eckenrode | That’s actually probably wrong. | 02:05:06 |
| emily | the only cases where SPI_AVAILABLE(…) should actually expand to a runtime check in anything we use is xnu headers that define APIs that tbh I literally cannot find code calling at all | 02:05:16 |
| Randy Eckenrode | That function is defined in libdyld/utils.cpp, which we don’t build. | 02:05:17 |
| emily | uh, shouldn't we be building it…? 🫠 | 02:05:56 |
| Randy Eckenrode | No. We don’t build libdyld.dylib. | 02:06:08 |
| Randy Eckenrode | We link against the system one. | 02:06:20 |
