Opened 5 years ago

Last modified 4 years ago

#59088 new defect

Xcode update broke linkages

Reported by: rhc54 (Ralph Castain) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.6.0
Keywords: xcode11 Cc: michaellass (Michael Lass), cainesi
Port:

Description (last modified by mf2k (Frank Schima))

Apple apparently included an Xcode update in a recent maintenance release. Since the update, I am unable to run many of the compiler ports (gcc, python) due to errors stating that system headers and libraries cannot be found. Investigation revealed that the ports were all configured with:

--with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk

However, the Xcode update apparently removed the MacOSX10.14.sdk and replaced it with MacOSX10.15.sdk - even though I have NOT updated the OS from Mojave!

I tried uninstalling all ports and reinstalling them, but that didn't help. Ditto for simply creating a MacOSX10.14.sdk symlink. Does anyone have a suggestion on how to get around this problem?

Change History (12)

comment:1 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)

Keywords: xcode headers removed

I guess you upgraded to Xcode 11. It is normal that Apple only includes the SDK for the most recent macOS in each new Xcode version, even if that is newer than your OS version.

I guess the path to the 10.14 SDK got baked into some ports in a way that impacts other ports. We'll have to identify all those places and fix each port not to do that.

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

It sounds like I would be smart to copy over the 10.14 SDK to /Library/Developer/CommandLineTools/SDKs/ before I upgrade Xcode...

comment:3 Changed 5 years ago by rhc54 (Ralph Castain)

Indeed - downgrading Xcode per suggestions on the user mailing list resolved the problem. The issues I encountered were with the gcc compilers, if that helps.

Meantime, I'll close this ticket as my problem has been resolved. Sorry for the noise. Apple slipped that one by me - my bad.

comment:4 Changed 5 years ago by kencu (Ken)

I think we're going to have to follow Apple's lead and use

--with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

comment:5 Changed 5 years ago by michaellass (Michael Lass)

Cc: michaellass added

comment:6 Changed 5 years ago by aivazis (Michael Aivazis)

In the meantime, can can someone show us how to generate a gcc specs file and drop it in the magic place to redirect sysroot to the new location?

comment:7 Changed 5 years ago by mf2k (Frank Schima)

Description: modified (diff)

In the future, please use WikiFormatting.

comment:8 Changed 5 years ago by mf2k (Frank Schima)

Keywords: xcode11 added

Sounds like an Xcode 11 issue.

comment:9 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)

Well, Apple has been doing this for years—releasing a new major version of Xcode that only contains the SDK for the then-most-recent version of macOS, even if that is later than the version of macOS you're running Xcode on. And this has not been a problem.

Xcode 11 is the first time this is causing a problem for us, because prior to macOS Mojave the command line tools provided headers that matched the OS version in /usr/include and we just used those. As of Mojave, that's no longer the case, so we had to use the SDK path. At the time, with Xcode 10, that was the 10.14 SDK path. Now that Xcode 11 is out, which doesn't have a 10.14 SDK, we're discovering all the places where the SDK path got baked into programs. It's the same problem I discovered years ago when investigating whether we should make MacPorts always use the SDK; see #41783.

I agree that if we used the unversioned MacOSX.sdk we would not have as bad a problem, and maybe that's what we should modify MacPorts base to do, though that still comes with the problem that it is specific to the Xcode installation directory, and thus requires that Xcode exists and is in its default location. Meanwhile effort has been put into allowing MacPorts to function better without needing Xcode to be installed; baking Xcode-relative SDK paths into programs defeats that.

I don't know of a solution that covers all bases.

comment:10 Changed 5 years ago by kencu (Ken)

I really think you should at least take a look at the ${SDKROOT} environment variable setting mechanism I have as a PR in macports-base.

It is a very powerful method of forcing the SDK to where you want it, skipping over much (not all) of the hiccups.

It was Jeremy's suggested method to me for setting the SDK in MacPorts properly last year when we first started on this issue (or at least I did).

Any tool that responds to xcrun will do the right thing.

I'm using that PR right now to build on Mojave against the MacOS10.7.sdk to test and triage build failures.

Last edited 5 years ago by kencu (Ken) (previous) (diff)

comment:11 Changed 5 years ago by cainesi

Cc: cainesi added

comment:12 Changed 4 years ago by thinkyhead (Scott Lahteine)

The sysroot / SDKROOT solutions didn't help me with the Catalina upgrade. But this does the trick:

sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs \
  /Library/Developer/CommandLineTools/SDKs
Note: See TracTickets for help on using tickets.