| 24 Oct 2025 |
 emily | so __SPI_AVAILABLE(macos(15.0), …) just means "this wasn't in dyld before macOS 15.0", I guess (why that's useful I don't know) | 01:35:18 |
| emily | when we're building the source releases ourselves it seems the public SDK behaviour of eliding those availability checks is exactly the correct thing | 01:35:48 |
| emily | https://github.com/search?q=repo%3Aapple-oss-distributions%2Flibdispatch%20dispatch_time_from_nsec&type=code another example | 01:36:15 |
| emily | so… all the darwin.AvailabilityVersions version of it would do is incorrectly mark stuff we're building as unavailable depending on SDK version, essentially | 01:37:10 |
 Randy Eckenrode | It probably depends on whether we’re linking to the implementation in one of the source releases or to the symbol exported by the system in the SDK. | 01:37:19 |
| emily | right | 01:37:28 |
| emily | but I think this stuff is mostly not exported by the SDK? | 01:37:36 |
| emily | because it's all stuff in private headers | 01:37:40 |
| Randy Eckenrode | The symbols are. | 01:37:42 |
| Randy Eckenrode | They’re in the text-based stubs. | 01:37:48 |
| emily | right, ok, dispatch_time_from_nsec is there | 01:38:06 |
| emily | it seems at least very contextual whether you'd want them to expand to availability checks | 01:38:16 |
| emily | like any time you're compiling something directly you don't want SPI_AVAILABLE on its own definitions | 01:38:48 |
| emily | what probably makes sense is rewriting SPI_ → API_ inside the XNU headers etc. themselves | 01:39:15 |
| Randy Eckenrode | I’d only want to elide them if we were actually building and using libdispatch on Darwin in lieu of using the system library. I would want those SPI checks in this case when using the system library because they may not be available on older releases. I ran into at least one of those with the 14.0 min version that required patching to check availability. | 01:39:25 |
| emily | libdispatch was just an example | 01:39:34 |
| emily | dyld is more relevant | 01:39:50 |
| emily | (since we actually build that) | 01:40:00 |
| emily | https://github.com/apple-oss-distributions/libpcap/blob/e5deb8a7884f6f0d24343e81dfd0a4585a03880a/libpcap/pcap-util.h#L61 | 01:40:37 |
| emily | we also build libpcap | 01:40:40 |
| Randy Eckenrode | The only libraries we build are ICU, libffi, libiconv, libresolv, libsbuf, libutil, and libpcap. | 01:40:44 |
| emily | though I guess we don't use the internal SDK for that | 01:40:47 |
| emily | we build the Mach-O lib in dyld at least… | 01:41:10 |
| emily | which has such annotations | 01:41:13 |
| Randy Eckenrode | Most things that want to use private libpcap symbols re-declare the function definition. Only Apple bothers to use the private headers. | 01:41:26 |
| Randy Eckenrode | It’s a static library that isn’t installed. | 01:41:57 |
| Randy Eckenrode | I did that to avoid having the same lists of files for multiple executables. | 01:42:45 |
| Randy Eckenrode | I do export the libdsc_extractor dylib though. | 01:43:14 |
| emily | fwiw, the repos that mention SPI_AVAILABLE are: libpthread, libmalloc, xnu, mDNSResponder, dyld, Security, WebKit, libdispatch, WebCore, configd, libplatform, libpcap, IOKitUser, Libinfo, eap8021x, libffi | 01:44:33 |
| emily | I think that the only time we'll be using headers with SPI_* stuff and not just wanting them to be elided (because we're building stuff ourselves and so it's available invariant of runtime OS version) is really just the xnu headers | 01:45:13 |
