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)
Change History (24)
Changed 3 years ago by pcmock
comment:1 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | MarcusCalhoun-Lopez added |
---|---|
Owner: | set to michaelld |
Status: | new → assigned |
Summary: | SDK problem → qscintilla-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.
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: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?
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 follow-up: 20 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 Changed 2 years ago by Kyshman (Tony Kinyua)
Replying to michaelld:
@Schamschula: in the Portfile for qscintilla-qt5 (
$(port dir qscintilla-qt5)/Portfile
), add inuse_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: | assigned → closed |
Duplicate of issue:62309, and resolved via: comment:23:issue:65293
port install qscintilla-qt5 log file