https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #27 from Chris Jones <jonesc at hep dot phy.cam.ac.uk> --- > Certainly, this is more about Xcode, not CLT. Not quite true, certainly not within MacPorts. See below. > > > > > 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. As far as we have a recommendation , it's to install *both* Xcode and the CLT. The reason being there are plenty of ports that are picky over which they build against. Many users attempt to only have the CLT installed, but they often run into problems with ports that simply will not build (or run) without a full Xcode installation. > > 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. Within mMacPorts, as much as we have recommendations, on having Xcode and/or CLT installed, and the versions of them, doing so in practise is akin to cat herding. Futile in practise. We encounter all possible combinations of CLT and/or Xcode, and any of the possible versions any OS could have. Thats simply just the reality we have to deal with. When a user has both the CLT and Xcode installed, builds will tend to favour the CLT SDKs *not* the Xcode ones (this is why what the CLT supplies is very relevant). and just going back to the SDKs the CLT supply, yes, they supply multiple versions, but only two are actual SDKs, the rest just sym links. e.g. on macOS15 I see Larissa ~/Projects/MacPorts/ports > ls -lth /Library/Developer/CommandLineTools/SDKs total 0 lrwxr-xr-x 1 root wheel 14B 20 Sep 19:47 MacOSX.sdk -> MacOSX15.0.sdk lrwxr-xr-x 1 root wheel 14B 20 Sep 19:46 MacOSX14.sdk -> MacOSX14.5.sdk lrwxr-xr-x 1 root wheel 14B 20 Sep 19:46 MacOSX15.sdk -> MacOSX15.0.sdk drwxr-xr-x 7 root wheel 224B 21 Aug 16:15 MacOSX15.0.sdk drwxr-xr-x 7 root wheel 224B 30 Apr 23:16 MacOSX14.5.sdk The 'default' (as much as there is one) SDK, MacOSX.sdk, will always point to the newest. The above is with the Xcode 16 CLT version. If a user on macOS14 has the same installed, they will see the same, so their 'default' will also be the macOS15 version. Yes, you could say 'just always use the version one then, for your OS'. The issue there is controlling what all possible build systems do when presented with the above is another exercise in cat herding... The simple bottom line is as long as Apple is in the habit of making available to macOS(N-1) the Xcode version for macOSN, and the SDKs that go with that, we have to live with builds using them. Attempting to control that is just impractical.
