| 24 Oct 2025 |
 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 |
| emily | fair enough | 02:09:38 |
| emily | maybe just doing a #define __SPI_AVAILABLE API_AVAILABLE etc. is the way to go for the internal SDK then | 02:10:03 |
| emily | at worst we'll have to patch it out in some places | 02:10:09 |
| Randy Eckenrode | Maybe it sucks less if we can use their Xcode project. We still need to get a Swift Build that can build something non-trivial. | 02:10:26 |
| Randy Eckenrode | As far as patching things, my ideal is building a source release without having to do anything to get it to build. | 02:11:26 |
| emily | well, if it's yelling at you about missing availability checks for a symbol defined in the same source release… | 02:13:11 |
