https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #25 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Mark Mentovai from comment #24) > (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). 1. but you have identified that this cannot work when symbols are removed from a library .. as we see here 2. That is definitely not the case for CLT - and I do not install Xcode (i have too many test boxes) $ ls /XC/14.1/CommandLineTools/SDKs/ MacOSX.sdk MacOSX12.3.sdk MacOSX12.sdk MacOSX13.0.sdk MacOSX13.sdk $ ls /XC/15.1b/CommandLineTools/SDKs/ MacOSX.sdk MacOSX13.3.sdk MacOSX13.sdk MacOSX14.0.sdk MacOSX14.sdk > > 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. this solution manifestly does work - since i use it - and the downstream projects like HB and macports, I thought recommended installing the CLT? .. however.... > > 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. You need to be very careful here - because of the fixincludes we have not been able to drop yet (and some that will be very hard to drop because the SDKs are incompatible with legal C and C++) this does mean that the SDK that the compiler was built with does matter to them. In some cases, this means the compiler will not function with a different SDK from the one it was built with. I wish we could drop all the fixincludes - or find an alternate solution - but until then we're stuck with this. Anyway - the bottom line is that I agree with removing the legacy lib from macOS 14 (even if we do not completely agree on the reasons) .. will try to test & push the patch ASAP
