MacOS and version 16 Software Development Kits

Apple have released version 16 of their Software Development Kits (SDKs). This note discusses the impact of this on users of released FSF GCC Ada compilers:

1. just the compiler, in Alire,
2. the compiler with a full suite of tools.

If you’re getting mysterious faiures with C or C++ compilations, this note is for you.

At the time of writing (8 November 2024) the fixes available for users of the first compiler are to avoid accepting the upgrade, or if installed to restore from backup (you may be able to download an appropriate version via the Apple Developer program).

Users of the second compiler should upgrade to release 14.2.0-2 or later, but beware, these won’t run on Monterey/SDK version 14.

Apple provide two SDK variants: Xcode (XC) and the Command Line Tools (CLT).

The macOS content of both flavours of SDK are the same (or at the very least compatible); the CLTs are much smaller, because they don’t include other targets (iPhone, WatchOS …).

SDKs version 16 are released for Sonoma (macOS 14) and Sequoia (macOS 15). The impact on GCC users is that a compiler built against a version 15 SDK will fail to compile C or C++ code using an SDK version 16 with errors like

/opt/gcc-14.2.0-1-aarch64/lib/gcc/aarch64-apple-darwin21/14.2.0/include-fixed/stdio.h:83:8: error: unknown type name ‘FILE’
   83 | extern FILE *__stdinp;
      |        ^~~~
/opt/gcc-14.2.0-1-aarch64/lib/gcc/aarch64-apple-darwin21/14.2.0/include-fixed/stdio.h:81:1: note: ‘FILE’ is defined in header ‘<stdio.h>’; this is probably fixable by adding ‘#include <stdio.h>’
   80 | #include <sys/_types/_seek_set.h>
  +++ |+#include <stdio.h>
...

Notice (you’ll probably need to scroll the above listing over to the right) that the errors occur in a directory include-fixed/. Files in this directory are created during compiler build using a “fixincludes” scheme.

The purpose of “fixincludes” is to handle the fact that OS developers (Apple in this case) don’t necessarily feel obliged to make sure that their SDK is standards-compliant, or at least GCC-compliant; and the fixed includes for a version 15 SDK don’t work on a system running version 16.

We could build compilers against an SDK version 16, but such a compiler fails on a system running version 15. This conflicts with our desire to support as many Mac users as possible.

The approach we’ve adopted for the suite releases is based on the internal structure of the SDKs.

You can find the SDK you have installed by

$ xcrun --show-sdk-path

which, in the case of the Command Line Tools version 16.1, will result in

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

That says SDKs (plural). Taking the hint and looking inside,

$ ls -l $(xcrun --show-sdk-path)/..
total 0
lrwxr-xr-x  1 root  wheel   14 31 Oct 14:06 MacOSX.sdk -> MacOSX15.1.sdk
drwxr-xr-x  7 root  wheel  224  8 Jul 09:09 MacOSX14.5.sdk
lrwxr-xr-x  1 root  wheel   14 31 Oct 14:05 MacOSX14.sdk -> MacOSX14.5.sdk
drwxr-xr-x  7 root  wheel  224 11 Oct 00:11 MacOSX15.1.sdk
lrwxr-xr-x  1 root  wheel   14 31 Oct 14:05 MacOSX15.sdk -> MacOSX15.1.sdk

so the default MacOSX.sdk goes to the MacOSX15.1sdk which matches this Mac, running Sequoia, 15.1, and there is also a version for the previous OS release (Sonoma, macOS 14)

The same exercise for CLT 15.3 gives

lrwxr-xr-x  1 root  wheel   14  6 Mar  2024 MacOSX.sdk -> MacOSX14.4.sdk
drwxr-xr-x  7 root  wheel  224 12 May  2023 MacOSX13.3.sdk
lrwxr-xr-x  1 root  wheel   14  6 Mar  2024 MacOSX13.sdk -> MacOSX13.3.sdk
drwxr-xr-x  7 root  wheel  224 20 Feb  2024 MacOSX14.4.sdk
lrwxr-xr-x  1 root  wheel   14  6 Mar  2024 MacOSX14.sdk -> MacOSX14.4.sdk

which also includes a MacOSX14.sdk as well as a version for the previous OS release (Monterey, macOS 13).

So, our arrangement is, we configure the compiler to build against MacOSX14.sdk by

$ export SDKROOT=$(xcrun --show-sdk-path)
$ configure \
  ...
  --sysroot=$SDKROOT/../MacOSX14.sdk \
  ...

This is a bit of a stopgap measure; we’ll have to develop a better solution by the time macOS 16 is released.