| 24 Oct 2025 |
 samasaur | so the thing that's odd is that it appears able to find CFNetwork but not Network | 01:51:07 |
| samasaur | despite everything appearing to be "found" the same way | 01:51:15 |
 Randy Eckenrode | It would probably be worth making the symbols always be available for libpcap and libffi, but most things that want to use them will redeclare them anyway. | 01:51:29 |
 emily | libpcap and libffi will already get them always available | 01:51:43 |
| emily | because the public SDK causes SPI_AVAILABLE(…) to expand to nothing | 01:51:51 |
| emily | correctly in this case | 01:51:56 |
| emily | the only time we ever don't want that behaviour is basically when we're hacking up xnu headers, I think | 01:52:39 |
| Randy Eckenrode | I don’t know that the private headers with those declarations are even included in the packages. We build both with their configure scripts. | 01:52:42 |
| emily | which is why I suggested the best approach is probably to replace SPI_ → API_ in xnu headers and have an empty AvailabilityInternalPrivate.h (or drop their includes of it) | 01:53:12 |
| emily | since that will ensure the right behaviour there without screwing up the more common uses of SPI_* in the source releases | 01:53:28 |
| emily | (where we do want them to be elided) | 01:53:33 |
| 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 |
