Opened 3 years ago

Closed 2 years ago

#64713 closed defect (duplicate)

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

Reported by: pcmock Owned by: michaelld (Michael Dickens)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), Kyshman (Tony Kinyua), chrstphrchvz (Christopher Chavez), cooljeanius (Eric Gallager), judaew (Vadym-Valdis Yudaiev), potmj (Michael Pot), Schamschula (Marius Schamschula)
Port: qscintilla-qt5

Description

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

Attachments (1)

main.log (129.5 KB) - added by pcmock 3 years ago.
port install qscintilla-qt5 log file

Download all attachments as: .zip

Change History (24)

Changed 3 years ago by pcmock

Attachment: main.log added

port install qscintilla-qt5 log file

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

Cc: MarcusCalhoun-Lopez added
Owner: set to michaelld
Status: newassigned
Summary: SDK problemqscintilla-qt5: xcrun: error: SDK "macosx11" cannot be located

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

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

Last edited 3 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

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

comment:4 Changed 3 years ago by Kyshman (Tony Kinyua)

Cc: Kyshman added

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

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

comment:7 Changed 3 years ago by chrstphrchvz (Christopher Chavez)

Cc: chrstphrchvz added

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

comment:9 Changed 3 years ago by chrstphrchvz (Christopher Chavez)

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

comment:10 Changed 3 years ago by michaelld (Michael Dickens)

Why Apple why???

comment:11 Changed 3 years ago by chrstphrchvz (Christopher Chavez)

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

comment:12 Changed 3 years ago by cooljeanius (Eric Gallager)

Cc: cooljeanius added

comment:13 Changed 2 years ago by judaew (Vadym-Valdis Yudaiev)

Cc: judaew added

comment:14 Changed 2 years ago by potmj (Michael Pot)

Cc: potmj added

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?

Last edited 2 years ago by potmj (Michael Pot) (previous) (diff)

comment:15 Changed 2 years ago by Schamschula (Marius Schamschula)

Cc: Schamschula added

comment:16 Changed 2 years ago by Schamschula (Marius Schamschula)

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

comment:17 Changed 2 years ago by 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!

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

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

comment:20 in reply to:  17 Changed 2 years ago by 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.

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

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

comment:23 Changed 2 years ago by mascguy (Christopher Nielsen)

Resolution: duplicate
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.