| 24 Oct 2025 |
 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 |
| Randy Eckenrode | If we link against it at all. | 02:06:32 |
| Randy Eckenrode | You’re right if we’re actually building and consuming something with private APIs, we want to remove the annotations to make sure that works correctly for consumers (including the build itself), but that’s not the case here. The dyld source release is pretty nasty, so I try to build as little as possible to get the tools I want out of it. | 02:08:50 |
