https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #24 from Mark Mentovai <mark at moxienet dot com> --- (In reply to Iain Sandoe from comment #23) > OK. I don't want to argue about the details / usability etc. etc. ( but note > that __symbols are for the implementation and the compiler is part of the > implementation ). In principle, we should have dialogue between the > compiler 'vendors' (we do upstream) - but usually the first we know about > what's happening with SDKs is when something does not work. I mentioned the __ thing only to illustrate how these are a little outside of the normal application of the SDK. Apple’s made it pretty clear over the years that they consider themselves to own the entire implementation, end-to-end, privately. This isn’t just a GCC problem. They’ve bought into clang in a very big way and contribute to open-source LLVM. Trunk clang still has incompatibilities with the newly released macOS 15 SDK (example: https://chromium-review.googlesource.com/c/5622510/comments/04615850_0139eb2f). > So, the solutions that work are: > > 1. when building for macOS 14, use the macOS 14 SDK (that is actually my > default action on all OS versions - use the last SDK provided for it). Infeasible, though. It’s been a very long time since Apple bundled more than one SDK per platform in Xcode. (The last time they did was Xcode 6.4 in 2015, with 10.9 and 10.10 SDKs, and some early Xcode 7.0 betas.) I really liked picking-and-choosing an appropriate SDK, but Apple decided that availability annotations were good enough for developer purposes and moved everything over to a single SDK only. > 2. Drop the legacy lib from macOS 14 as well. > > given that users will probably just use what xcrun gives them, 2 (as you > propose) is probably least likely to get us a lot of bogus bug reports. Yeah, exactly. It’s not even going to be a matter of “what xcrun gives them”, there will be a large enough number of macOS 14 systems with developer tools but a macOS 15 SDK instead of a macOS 14 SDK. The SDKs are going to be updated in the wild, I don’t think GCC has much of an option to try to require that macOS 14 stick with that exact SDK.
