| 24 Oct 2025 |
 Randy Eckenrode | We shouldn’t be hacking up xnu headers. We should actually be building them because that sucks a lot less than what we are currently doing. | 01:53:35 |
 emily | define "actually building them"? | 01:54:17 |
| emily | I don't think we can avoid modifying them in some way | 01:54:36 |
| Randy Eckenrode | The xnu makefiles have a target for building the headers. | 01:54:37 |
| emily | fundamentally we are not actually running our own XNU at runtime | 01:54:46 |
| Randy Eckenrode | The old source releases used to do it, but they made a mess pf the result. | 01:55:06 |
| Randy Eckenrode | * | 01:55:13 |
| 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 |
