qscintilla-qt5: xcrun: error: SDK "macosx11" cannot be located

[pcmock]

Error message:

--->  Configuring qscintilla-qt5
xcrun: error: SDK "macosx11" cannot be located
Error: Failed to configure qscintilla-qt5: configure failure: command execution failed

My OS = 11.6.4. xcrun info:

sh-3.2# xcrun --sdk macosx11 --show-sdk-path 
xcodebuild: error: SDK "macosx11" cannot be located.
xcodebuild: error: SDK "macosx11" cannot be located.
xcrun: error: unable to lookup item 'Path' in SDK 'macosx11'
sh-3.2# xcrun --sdk macosx --show-sdk-path 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk

SDK directory info:

sh-3.2# pwd
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
sh-3.2# ls -l
total 0
drwxr-xr-x  7 root  wheel  224 Dec 18 11:24 MacOSX.sdk
lrwxr-xr-x  1 root  wheel   10 Dec 15 14:34 MacOSX12.1.sdk -> MacOSX.sdk

[pcmock]

port install qscintilla-qt5 log file

[ryandesign (Ryan Carsten Schmidt)]

Looks like a duplicate of either of the other two open qscintilla-qt5 tickets.

[pcmock]

I've tried the alias and ln -s fixes in those tickets. I've also had a similar problem with qt5-qtbase reported in ticket 62934 (9 months ago), and I tried editing the SDK lines in macx.conf too. This time none of these "fixes" work. I've looked at a few other qt5 related tickets, and this problem seems to recur sporadically. I'm sure the fix is similar to what I've already tried, but it's still hard to find.

[Kyshman (Tony Kinyua)]

While installing QGIS3 I got this

:info:build /opt/local/libexec/qt5/bin/qmake -recursive QScintilla.pro
:info:build sip-build-3.10: '/opt/local/libexec/qt5/bin/qmake -recursive QScintilla.pro' failed returning 3
:info:build Project ERROR: Could not resolve SDK Path for 'macosx11' using --show-sdk-path

My OS: 11.6.5 xcrun info:

fish>> xcrun --sdk macosx11 --show-sdk-path
xcodebuild: error: SDK "macosx11" cannot be located.
xcodebuild: error: SDK "macosx11" cannot be located.
xcrun: error: unable to lookup item 'Path' in SDK 'macosx11'

fish>> xcrun --sdk macosx --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk

Tried the suggestions here and the other ​open qscintilla-qt5 tickets

None worked so changed tact and edited the file /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/python/py-pyqt5-scintilla/work/QScintilla-2.13.2/.qmake.cache and changed the following;

QMAKE_MACOSX_DEPLOYMENT_TARGET=11.0 to QMAKE_MACOSX_DEPLOYMENT_TARGET=11.3

QMAKE_MAC_SDK=macosx11 to QMAKE_MAC_SDK=macosx11.3

The configure, build & install process was then successful.

Hopefully this wont cause any issues until the next upgrade.

[michaelld (Michael Dickens)]

I see this issue on my macOS 11 boot system as well, where the QMAKE_MAC_SDK is set to macosx11. I've debugged to the point of believing it's a difference between the SDK info installed into /Library/Developer/CommandLineTools/SDKs/ and xcrun --show-sdk-path -- which may or not be the same; for me this latter is /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk:

% ls -lAF /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
total 0
drwxr-xr-x  5 root  wheel  160 Nov 30  2020 DriverKit20.2.sdk/
drwxr-xr-x  7 root  wheel  224 Nov 30  2020 MacOSX.sdk/
lrwxr-xr-x  1 root  wheel   10 Dec 19  2020 MacOSX11.1.sdk@ -> MacOSX.sdk

% ls -lAF /Library/Developer/CommandLineTools/SDKs/
total 0
lrwxr-xr-x  1 root  wheel   14 Dec 14 08:53 MacOSX.sdk@ -> MacOSX12.1.sdk
drwxr-xr-x  8 root  wheel  256 Jun 24  2021 MacOSX10.15.sdk/
drwxr-xr-x  7 root  wheel  224 Jun 24  2021 MacOSX11.1.sdk/
drwxr-xr-x  7 root  wheel  224 Jul 12  2021 MacOSX11.3.sdk/
lrwxr-xr-x  1 root  wheel   14 Dec 14 08:51 MacOSX11.sdk@ -> MacOSX11.3.sdk
drwxr-xr-x  7 root  wheel  224 Nov 19 17:25 MacOSX12.1.sdk/
lrwxr-xr-x  1 root  wheel   14 Dec 14 08:50 MacOSX12.sdk@ -> MacOSX12.1.sdk

I believe the logic in portconfigure.tcl needs to be updated for this sort of use case. That said, these are what I _think_ and _believe_ rather than have confirmed as a bug or fix.

[chrstphrchvz (Christopher Chavez)]

I wonder if the use_xcode yes workaround (or if {${xcodeversion} ne "none"} {use_xcode yes} if command line tools are sufficient) applies to this issue as well.

If so, then it seems that however Qt/Qmake are doing SDK detection assumes the Xcode SDK rather than the CLT SDK is used if Xcode is installed (and used by xcrun), but MacPorts is trying to have ports use the CLT SDK whenever Xcode isn’t requested (with use_xcode yes).

[michaelld (Michael Dickens)]

Maybe that's the issue: MP is trying to use CLT but clearly QMake is using xcrun which is Xcode ... hence one finds one SDK that the other won't find. Let me try the use_xcode you note & see if that helps.

[chrstphrchvz (Christopher Chavez)]

Note that CLT does have xcrun; it just seems to behave slightly differently when Xcode is installed.

[michaelld (Michael Dickens)]

Why Apple why???

[chrstphrchvz (Christopher Chavez)]

(My guess is that xcrun predates the ability to install CLT separately without full Xcode.)

[potmj (Michael Pot)]

I guess this is all to do with ​https://developer.apple.com/forums/thread/62870 in that the SDK & CLT can now differ! Indeed, why, why, why, Apple?

[Schamschula (Marius Schamschula)]

I'm also seeing this under macosx12 on an M1 machine.

[michaelld (Michael Dickens)]

@Schamschula: in the Portfile for qscintilla-qt5 ($(port dir qscintilla-qt5)/Portfile), add in use_xcode yes ... I have it at line 28. Clean qscintilla-qt5 then try installing again. This works for me for qscintilla-qt5, py*-pyqt5, and py*-pyqt5-qscintilla. Hope it works for you too!

[kencu (Ken)]

I'm not sure how we can reliably get around this issue with all the ports that use xcrun without requiring xcode.

If I have analyzed it correctly, issue seems to be that xcrun will not work properly on newer systems if the user has xcode installed but macports sets the DEVELOPER_DIR to the CLTs (as it does by default).

If the user does not have xcode installed, I think it works fine, and xcode is not actually needed, though. (You can test this by moving your Xcode.app to Xcode-somethingelse.app and retrying the build without adding "use_xcode yes").

So if that turns out to be true, xcode is really not needed, we just need to sort out how to set DEVELOPER_DIR in base properly. It may be too hard / too much trouble to go through all those proper steps, though -- assuming that analysis turns out to be right.

[michaelld (Michael Dickens)]

Interesting! I'll try to allocate some time to experiment with DEVELOPER_DIR now ... very curious how that might impact this issue!

[Kyshman (Tony Kinyua)]

Replying to michaelld:

@Schamschula: in the Portfile for qscintilla-qt5 ($(port dir qscintilla-qt5)/Portfile), add in use_xcode yes ... I have it at line 28. Clean qscintilla-qt5 then try installing again. This works for me for qscintilla-qt5, py*-pyqt5, and py*-pyqt5-qscintilla. Hope it works for you too!

My solution is to set

macosx_deployment_target	12.3

and

macosx_sdk_version	12.3

in macports.conf.

Once I install whatever was dependant on the *qscintilla* family ports I then disable my entries in macports.conf.

[kencu (Ken)]

there is some stuff here:

​https://github.com/macports/macports-ports/pull/15136

and some experiments here:

​https://trac.macports.org/ticket/65293

and a scattering of several dozen other tickets where this issue frustrated people, but I don't think with any other helpful info in those other than examples of the errors.

[LenoreHorner]

Adding use_xcode yes at line 28 also worked for me on 11.6.5 with Xcode 13.2.1 and CLT installed. Thanks for the instructions (and the reminder about how to find where the portfile is).

[mascguy (Christopher Nielsen)]

Duplicate of issue:62309, and resolved via: comment:23:issue:65293