Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#57143 closed defect (fixed)

Unable to determine location of a macOS SDK

Reported by: ivanatina Owned by: jmroot (Joshua Root)
Priority: Normal Milestone: MacPorts 2.6.0
Component: base Version: 2.5.99
Keywords: Cc: tgyurci (Teubel György), jeremyhu (Jeremy Huddleston Sequoia), kencu (Ken), ryandesign (Ryan Schmidt), thenickdude (Nicholas Sherlock)
Port:

Description

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

Change History (22)

comment:1 Changed 3 years ago by jmroot (Joshua Root)

Milestone: MacPorts Future

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

comment:2 Changed 3 years ago by ryandesign (Ryan 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.

comment:3 Changed 3 years ago by 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.

comment:4 Changed 3 years ago by tgyurci (Teubel György)

Cc: tgyurci added

comment:5 Changed 3 years ago by 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.

comment:6 Changed 3 years ago by 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.

comment:7 Changed 3 years ago by 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

comment:8 Changed 3 years ago by 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.

comment:9 Changed 3 years ago by 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.

comment:10 Changed 3 years ago by jmroot (Joshua Root)

Cc: jeremyhu added
Component: portsbase
Summary: $port $version [$variants]: Unable to determine location of a macOS SDKUnable to determine location of a macOS SDK
Version: 1.7.02.5.99

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

comment:11 Changed 3 years ago by 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.

comment:12 Changed 3 years ago by 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.

comment:13 Changed 3 years ago by 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).

comment:14 in reply to:  13 Changed 3 years ago by ryandesign (Ryan Schmidt)

Cc: kencu ryandesign added

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.

comment:15 Changed 3 years ago by ryandesign (Ryan 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.

comment:16 Changed 2 years ago by jmroot (Joshua Root)

Owner: set to jmroot
Resolution: fixed
Status: newclosed

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

comment:17 Changed 2 years ago by jmroot (Joshua Root)

Milestone: MacPorts Future

comment:18 Changed 2 years ago by jmroot (Joshua Root)

Milestone: MacPorts FutureMacPorts 2.6.0

comment:19 Changed 2 years ago by 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 ...?

comment:20 Changed 2 years ago by kencu (Ken)

comment:21 Changed 2 years ago by czender (Charlie Zender)

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

comment:22 Changed 2 years ago by thenickdude (Nicholas Sherlock)

Cc: thenickdude added
Note: See TracTickets for help on using tickets.