The Missing MacOSX10.14.sdk

Posted on 2 mins read

Introduction

Some ports in MacPorts would bake the platform SDK paths into build flags used to build dependent ports. For example, the ruby24 port remembers its build flags in the rbconfig.rb file, and uses these flags to build gems with native C extensions.

# /opt/local/lib/ruby2.4/2.4.0/x86_64-darwin18/rbconfig.rb
  CONFIG["CPPFLAGS"] = "-I/opt/local/include -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -D_DARWIN_UNLIMITED_SELECT -D_REENTRANT $(DEFS) $(cppflags)"
  CONFIG["LDFLAGS"] = "-L. -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -fstack-protector -L/opt/local/lib"
  CONFIG["CFLAGS"] = "-pipe -Os -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -fno-common"

So when macOS Mojave users upgrade to Xcode 11, which only provides MacOSX10.15.sdk under /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs, all gems with extensions would fail to build.

The CLT (Command Line Tools) is built against a specific version of macOS, so it guarantees the existence of its SDK path, e.g. /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk, and that’s why we now recommend users to always install the CLT.

Transcript

Subject: Re: OpenBLAS fixed in Xcode 11.2

From: Ryan Schmidt

On Nov 3, 2019, at 03:52, Chris Jones wrote:

Hi,

On 2 Nov 2019, at 4:56 pm, Ryan Schmidt wrote:

Josh told me when Mojave was released that we weren’t installing the CLT anymore on the builders.

Then when Xcode 11 came along and we had zillions of problems building things with it on Mojave without the CLT, Josh said we were changing our recommendation back to installing the CLT.

So that’s what I then did on the Mojave builder, and when I set up the Catalina worker.

Thats understandable, but the problem is upgrading Xcode to 11.2 does not help as much when the CLT tools are still stuck at the buggy older version, as if both are installed the older CLT SDK is now preferred, so builds still fail. Hopefully

https://github.com/macports/macports-ports/pull/5673

Will help a bit, And also hopefully Apple will not be too long in releasing an updating CLT that is also fixed….

The fact that the CLT SDK is now preferred is another reason why we want to go back to requiring the CLT. After Xcode 11 was released and Mojave users upgraded to it, we discovered just how pervasive the problem of SDK paths baked into build scripts was, as zillions of bug reports started pouring in about the MacOSX10.14.sdk being missing. Having the CLT installed on the build server ensures that any SDK paths that do get baked in will be for something that continues to exist even if Xcode is upgraded or is not present.