| 24 Oct 2025 |
 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 |
| emily | then there is no choice, something needs adjusting. | 02:13:25 |
| Randy Eckenrode | That’s something that can be tackled when the time comes. | 02:14:14 |
| Randy Eckenrode | One thing I would like to do with this is enable the tests. There are actual tests in many of these source releases, but I’m not willing to rig them up to Meson. I did libiconv because I wanted to make sure things were actually working correctly. | 02:14:44 |
| emily | hence "at worst" | 02:15:00 |
| emily | we still should avoid having availability headers that are randomly inconsistent between the internal and public SDK though, which is why just doing the #define will work better if we do want __SPI_AVAILABLE across the board | 02:15:29 |
| emily | no way out of having some custom headers given CoreSymbolication and all | 02:15:54 |
| Randy Eckenrode | And APFS.framework. | 02:16:21 |
| emily | btw, I don't think I understand the atf infinite recursion thing. why does doing it in the stdenv not work with pkgsStatic? | 02:16:31 |
| Randy Eckenrode | I think I’ve done a few others as well. That’s expected. | 02:16:33 |
| emily | because pkgsStatic is cross so it skips the override and then the static apple-sdk infrecs? | 02:16:51 |
| Randy Eckenrode | Yeah. ATF needs to be in checkInputs and nativeCheckInputs because it provides a runner and a library you need to link. For pkgsStatic, that library is pkgsStatic.atf, which depends on the SDK, which depends on pkgsStatic.libiconv, which depends on pkgsStatic.atf. | 02:18:16 |
| Randy Eckenrode | Native stdenvs can untie that knot with overrides, but cross ones either can’t or don’t. | 02:18:37 |
| emily | perhaps we should propagate the extra packages from the stdenv rather than apple-sdk | 02:18:41 |
| Randy Eckenrode | It wouldn’t matter where it’s propagated. | 02:19:03 |
| Randy Eckenrode | The static stdenv would depend on pkgsStatic.libiconv, which etc. | 02:19:30 |
