https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #26 from Mark Mentovai <mark at moxienet dot com> --- (In reply to Iain Sandoe from comment #25) > 1. but you have identified that this cannot work when symbols are removed > from > a library .. as we see here Apple never really removes symbols that were ever a part of a public interface in an SDK, because it would create a compatibility problem. What happened here is a special case, because those symbols were never part of a public interface, and nobody ever referenced them. Except GCC did, which is why we’re here. But I’d be surprised if GCC ever used them in a meaningful way, since they never actually worked. (They were broken for 2 OS releases, and no-ops for the rest of time.) Had there ever been a public declaration, I don’t think Apple would have removed them. But the point stands that you’re inside of implementation territory, which Apple treats as private and owned end-to-end by them, and so GCC and even open-source LLVM are very much in “your mileage may vary” territory. > 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 Certainly, this is more about Xcode, not CLT. > > > 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? Some do, I don’t know about all. Nevertheless, I use MacPorts quite successfully on systems with only Xcode and no CLT. I don’t think it’d be prudent for GCC to require a particular flavor of OS toolchain and SDK installation, though. There will be machines in the wild with nothing but Xcode on them. > .. 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. Yes, it’s unfortunate, but you do need to treat a GCC installation as locked to the SDK that it was built against, precisely because of the fixincludes. > 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 Thank you!
