MacOS Software Development Kit changes

This post is based on the README from the corresponding Github repository.

That repository attempts to cope with expected changes in Apple’s approach to software development kits, specifically where to find the system headers (you’d expect /usr/include).

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).

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.

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.

You do the installation 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.

So, what to do about it?

GNAT CE 2019

AdaCore’s GNAT GE 2019 release 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 prefix you actually need is /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk.
• 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).

FSF GCC

A similar problem arises with FSF GCC, builds provided at Sourceforge.

The approach I’m planning to adopt for future releases is to disable System Integrity Protection (which prevents altering important system directories, and is normally Not Recommended) and copy usr/include from inside whichever SDK is installed to the normal place, then build the compiler as normal.

For users who haven’t done this (the majority, I expect and hope) I’ll provide a modified specs on the same lines. 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).