| 24 Oct 2025 |
 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 |
| emily | funny header name: SecProtocolRestrictedOptionsGoAwayIfNotApprovedForEPSKsPriv.h | 01:45:28 |
 samasaur | any idea why qt can't find Network.framework | 01:47:16 |
| emily | uhh | 01:48:19 |
| emily | did it -framework it? | 01:48:21 |
| samasaur | https://github.com/qt/qtbase/blob/e902f8ad85a3a36b266f5e96bf3dc1ddad9fa18e/cmake/QtFrameworkHelpers.cmake#L42 | 01:48:34 |
| samasaur | can't find it at configure time, not build time | 01:48:45 |
| emily | have you looked at our Qt patches | 01:49:31 |
| samasaur | oh dear | 01:49:42 |
| samasaur | no | 01:49:43 |
| emily | they're not as bad as they used to be | 01:49:58 |
| emily | find_library(${cache_var_name} "${framework_name}")
if(${cache_var_name} AND ${cache_var_name} MATCHES ".framework$")
set(${out_var} "-framework ${framework_name}" PARENT_SCOPE)
else()
set(${out_var} "${out_var}-NOTFOUND" PARENT_SCOPE)
endif()
| 01:50:09 |
| emily | hmm I hope I didn't break CMake's ability to find frameworks | 01:50:14 |
