Skip to content
Provides GCC 'specs' files to cope with SDK policy changes
Ada C++ C Fortran
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.gitignore
README.md
ce2019-specs
gcc9-specs
hello.adb
hello.c
hello.cc
hello.f

README.md

MacOS Software Development Kit changes

These are experiments 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.

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

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

You can’t perform that action at this time.