Unable to determine location of a macOS SDK

[ivanatina]

Unable to execute port: can't read "configure.sdkroot": Unable to determine location of a macOS SDK.

[jmroot (Joshua Root)]

There's not enough information in this ticket to act on. At minimum we need to know what you did before seeing this message, and the environment in which you did it. A log file would be very helpful.

(Also it seems very unlikely that you are actually running MacPorts 1.7.0.)

[ryandesign (Ryan Carsten Schmidt)]

When the ​Trac ticket guidelines say to begin the summary with "$port $version [$variants]", you're mean to replace those placeholders with the actual port, port version, and port variants that you were trying to install when you found the error.

[tgyurci (Teubel György)]

This occurs after upgrading Xcode to 10.0 on macOS 10.13. The latest (10.0) Xcode does not include SDK for macOS 10.13, only for 10.14. Because of this, the only found macOS SDK version is newer than the base system. There is a commented workaround for this problem at the end of portconfigure::configure_get_sdkroot.

[jmroot (Joshua Root)]

Again, what are you doing when this happens? Most ports should not be using an sdkroot at all if the deployment target matches the current OS version.

[tgyurci (Teubel György)]

The default value for configure.sdkroot is set with portconfigure::configure_get_sdkroot which is called at configuring any port, if I'm right, but at my case the failing port is sqlite3. This procedure fails, if there is no MacOSX${macosx_version}.sdk. This is the case after upgrading to Xcode 10.0 on macOS 10.13.

This may be related to #56619

P.S.: I am not the original reporter of this issue.

[jmroot (Joshua Root)]

Yes configure_get_sdkroot is called, but in most cases it should return an empty string here: ​https://github.com/macports/macports-base/blob/v2.5.3/src/port1.0/portconfigure.tcl#L409

[raimue (Rainer Müller)]

Xcode has provided the very latest SDK only for quite a while already. So using the 10.(X+1) SDK on 10.X is not unheard of. Did you also install the latest Command Line Tools?

Could you provide a main.log showing the failure? Please be more specific with which port you encountered this problem and please try to provide steps to reproduce the issue.

[tgyurci (Teubel György)]

I did not notice that check in portconfigure.tcl and I have not installed the Command Line Tools. My bad, sorry.

[jmroot (Joshua Root)]

On the other hand, if we no longer warn about the lack of /usr/include, that commented workaround is probably necessary for some configurations?

[vtjnash (Jameson Nash)]

I saw this recently too. I'm on 10.13 with latest XCode (10.0).

Here's an example port action that tried to read this information and failed:

~$ sudo port deactivate python27
Error: Unable to determine location of a macOS SDK.
Error: python27: Error executing universal: can't read "configure.sdkroot": Unable to determine location of a macOS SDK.
Warning: Failed to open Portfile from registry for python27 @2.7.15_1+universal
Note: It is not recommended to uninstall/deactivate a port that has dependents as it breaks the dependents.

I also at other times got the warning that I should run xcode-select --install. Perhaps this message could be improved however. Standalone, it seems fine, but if you run `xcode-select --install', the dialog box that pops up presents XCode as a valid alternative. This is especially confusing because it used to actually be that XCode was required.

~$ sudo port install nodejs10
Warning: System headers do not appear to be installed. Most ports should build correctly, but if you experience problems due to a port depending on system headers, please file a ticket at https://trac.macports.org.
Warning: You can install them as part of the Xcode Command Line Tools package by running `xcode-select --install'.

And just one more note, I tested that with forcing 10.14 it works:

echo macosx_sdk_version 10.14 | sudo tee -a /opt/local/etc/macports/macports.conf

and also that installing the Developer Tools through xcode-select --install makes it work.

[jmroot (Joshua Root)]

Our installation instructions specify that you should have both Xcode and the Command Line Tools. The issue is that on Mojave, having the CLT doesn't guarantee the existence of /usr/include, and eventually there will probably be an Xcode release that runs on 10.14 but only includes the 10.15 SDK.

[kencu (Ken)]

I'm thinking that (at least on fairly current Xcode versions) it might be best to always build against the newest SDK that is available, but with a deployment target to match the current OS. Is that newest SDK available always going to be MacOSX.sdk now? If so, that makes it easy.

To do anything fancy (like build 32bit on Mojave or build 32bit with Xcode10 on High Sierra) you'd have to force an older SDK using the sdk Port that Ryan is working on).

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

I'm thinking that (at least on fairly current Xcode versions) it might be best to always build against the newest SDK that is available, but with a deployment target to match the current OS. Is that newest SDK available always going to be MacOSX.sdk now? If so, that makes it easy.

Yes, MacOSX.sdk is always the newest-available SDK. Yes, it would be better to use MacOSX.sdk rather than MacOSX10.14.sdk because these SDK paths get baked into the files that some ports install, and it would be better to bake in a path that will not disappear in a later version of Xcode. The fact that these paths get baked in was the reason why I had ultimately abandoned the idea of always using an SDK last time I investigated it, but now that /usr/include is gone we have no other choice. Users will still run into problems if they get a binary from our server with baked-in Xcode-relative SDK paths but the user has only installed the command line tools and not Xcode.

[ryandesign (Ryan Carsten Schmidt)]

Currently, MacPorts base sets the default SDK version to the macOS version, and then when determining which SDK path to use, it returns early and doesn't use an SDK if the SDK version is the same as the macOS version. What we should probably do instead is default the SDK version to empty. And when it's empty, we can default to the newest SDK. That way we can actually distinguish between a port that has requested a specific SDK vs. a port that does not care and can use the latest one.

[jmroot (Joshua Root)]

In 8caac195a15c8a01d07cf337439fd68f4370d9ee/macports-base (master):

Allow falling back to "macosx" SDK

In the past, we could use the Command Line Tools as effectively an SDK
installed in /. That's no longer possible starting with 10.14, so when
an Xcode version is released that will run on 10.14 but doesn't come
with a 10.14 SDK, we'll break. This works around that, though it comes
with its own set of problems.

Closes: #57143

[czender (Charlie Zender)]

After being forced to upgrade from port 2.5.4 (I think) to port 2.6.0 and to Xcode 11 a few days ago, I started receiving this error when upgrading ports:

Warning: Unable to determine location of the macOS 10.14 SDK.  Using the default macOS SDK.

Simultaneously (so far as I can determine) the gcc9 port (which updated from gcc 9.1 to 9.2 at the same time) started failing to link. Compiling and linking a trivial testfile conftest.c (which autoconf does a lot of) fails, i.e.,

gcc-mp-9 conftest.c

fails with

ld: library not found for -lSystem

Do you think this problem is related to this ticket or should I open a new ticket or ...?

[kencu (Ken)]

Charlie, look here <​https://trac.macports.org/ticket/59113>

[czender (Charlie Zender)]

Thank you so much for pointing me to this. I'm not alone!