MacOS Software Development Kit changes

Apple's development environment is Xcode. They provide a cut-down version called the Command Line Tools for those of us who don't need to develop for iPhone or Apple Watch. Xcode includes SDKs for those platforms, the Command Line Tools just for macOS (MacOSX, internally).

System includes

Up until Mojave, the Command Line Tools (which you get by xcode-select --install) automatically installed /usr/include. Apple's developer tools (clang etc) know where to find the includes in the current SDK, but GCC doesn't.

With Mojave, you need to install the headers by

$ sudo installer -pkg /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg -target /
Password:
installer: Package name is macOS_SDK_headers_for_macOS_10.14
installer: Installing at base path /
installer: The install was successful.

However, Apple say

As a workaround, an extra package is provided which will install the headers to the base system. In a future release, this package will no longer be provided.

So, what to do about it?

GNAT CE 2019

This work is prompted by AdaCore's GNAT GE 2019 release, which anticipates the lack of /usr/include by building the compiler using a system root inside the Xcode SDK:

--with-specs='%{!sysroot=*:--sysroot=%:xcode-path(/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk)}'

The xcode-path() bit appended its argument to Xcode's path on their development machine, /Applications/Xcode.app/Contents/Developer, which is OK so long as you actually have Xcode installed. It looks under that prefix for usr/include, usr/lib. But

• If you only have the Command Line Tools, the path you actually need is /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include.
• The compiler can't find /usr/local/include or /usr/local/lib (because it's looking under the Xcode SDK).

The first problem is fixable: install Xcode!
You can fix the second by -I/usr/local/include, -L/usr/local/lib.

An alternative (without installing Xcode) would be to copy ce2109-specs to $prefix/lib/gcc/x86_64-apple-darwin17.7.0/8.3.1/specs (ce2019-specs was generated by gcc -dumpspecs and judicious editing).

GNAT CE 2020

The changes here are very similar to those for GNAT CE 2019, but read ce2020-specs for ce2019-specs.

However! while these changes are fine for Mojave and Catalina, they don't work on Big Sur. You'll have to use the unmodified GNAT CE.
This seems to be because of an interaction between the extreme hairiness of the GCC specs system and Big Sur's ld (Apple's ld has always had more options than you could shake a stick at).

FSF GCC

A similar problem arises with FSF GCC, builds provided at Sourceforge. So far I've been building on El Capitan, which has none of these problems, but this approach will have to stop when the built compiler won't run on new macOS versions. A problem for another day! but, for now, the built compiler needs to be taught to look in the SDK.

I'm providing a modified specs on the same lines as above. gcc9-specs is the version for GCC 9.1.0; it adds both possible SDKs to the include search path, GCC will take the first one it finds (absent /usr/include). gcc10-specs is included (as just specs) in the native GCC 10.1.0 release at Sourceforge.

Big Sur and system libraries

With Big Sur, Apple have carried this approach through to system libraries; there's no /usr/lib, instead the libraries that you need to link against are in the SDKs. The symptom of this problem is that FSF GCC won't link, reporting

 ld: library not found for -lSystem

and the fix is to include -L$SDK/usr/lib in the linker command. This is in the latest version of gcc10-specs (commit cb87934).

You can use this without installing by e.g. for Ada

gnatmake hello.adb -largs -specs=gcc10-specs

or for C (or C++, or Fortran!) by

gcc hello.c -specs=gcc10-specs

You can install the change by copying gcc10-specs to $prefix/lib/gcc/x86_64-apple-darwin15/10.1.0/specs (note the file name change).