qmake5 PortGroup only works if use_xcode yes is applied to every PortFile that uses it: Project ERROR: Could not resolve SDK Path for 'macosx11' using --show-sdk-path

[cooljeanius (Eric Gallager)]

I'm on Big Sur with Xcode 13.2.1:

--->  Configuring qtads
DEBUG: Preferred compilers: clang macports-clang-14 macports-clang-13 macports-clang-12 macports-clang-11 macports-clang-10 macports-clang-9.0
DEBUG: Using compiler 'Xcode Clang'
DEBUG: Executing proc-pre-org.macports.configure-configure-0
DEBUG: qt5 PortGroup: Qt is provided by qt5
DEBUG: Executing proc-pre-org.macports.configure-configure-1
DEBUG: Active variants check for source-type install considers depends_fetch depends_extract depends_lib depends_build depends_run: xz libsdl2 libsndfile mpg123 fluidsynth libvorbis qt5-qtbase qt5-qtsvg pkgconfig
DEBUG: Executing proc-pre-org.macports.configure-configure-2
DEBUG: QT5 Qmake Cache /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_games_qtads/qtads/work/qtads-3.3.0-source/.qmake.cache
DEBUG: qt5-qtbase is installed with the following variants: +debug+examples+openssl+tests
DEBUG:   required: debug, forbidden: 
DEBUG:   accepted
DEBUG: Executing org.macports.configure (qtads)
DEBUG: Environment: 
CC='/usr/bin/clang'
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_games_qtads/qtads/work/.CC_PRINT_OPTIONS'
CFLAGS='-pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch x86_64'
CPATH='/opt/local/include'
CPPFLAGS='-I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk'
CXX='/usr/bin/clang++'
CXXFLAGS='-pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch x86_64'
DEVELOPER_DIR='/Library/Developer/CommandLineTools'
F90FLAGS='-pipe -Os -m64'
FCFLAGS='-pipe -Os -m64'
FFLAGS='-pipe -Os -m64'
INSTALL='/usr/bin/install -c'
LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch x86_64'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='11.0'
MACPORTS_LEGACY_SUPPORT_DISABLED='1'
OBJC='/usr/bin/clang'
OBJCFLAGS='-pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch x86_64'
OBJCXX='/usr/bin/clang++'
OBJCXXFLAGS='-pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch x86_64'
SDKROOT='/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk'
Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_games_qtads/qtads/work/qtads-3.3.0-source" && /opt/local/libexec/qt5/bin/qmake PREFIX=/opt/local -spec macx-clang 
DEBUG: system:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_games_qtads/qtads/work/qtads-3.3.0-source" && /opt/local/libexec/qt5/bin/qmake PREFIX=/opt/local -spec macx-clang 
Project ERROR: Could not resolve SDK Path for 'macosx11' using --show-sdk-path
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_games_qtads/qtads/work/qtads-3.3.0-source" && /opt/local/libexec/qt5/bin/qmake PREFIX=/opt/local -spec macx-clang 
Exit code: 3
Error: Failed to configure qtads: configure failure: command execution failed
DEBUG: Error code: NONE
DEBUG: Backtrace: configure failure: command execution failed
    while executing
"$procedure $targetname"
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_games_qtads/qtads/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.

[cooljeanius (Eric Gallager)]

main.log for qtads

[kencu (Ken)]

the qmake5 PortGroup recently had ​changes to it that make it only work if this is added to every PortFile that uses the PortGroup:

use_xcode yes

basically, the above change makes xcrun call through to xcodebuild, and that is only invoked by MacPorts if use_xcode yes is in the Portfile it would seem.

% /usr/bin/xcrun --sdk macosx --show-sdk-path
2022-06-04 10:47:50.901 xcodebuild[4258:85644] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionSentinelHostApplications for extension Xcode.DebuggerFoundation.AppExtensionHosts.watchOS of plug-in com.apple.dt.IDEWatchSupportCore
2022-06-04 10:47:50.902 xcodebuild[4258:85644] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionPointIdentifierToBundleIdentifier for extension Xcode.DebuggerFoundation.AppExtensionToBundleIdentifierMap.watchOS of plug-in com.apple.dt.IDEWatchSupportCore
2022-06-04 10:47:51.944 xcodebuild[4259:85660] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionSentinelHostApplications for extension Xcode.DebuggerFoundation.AppExtensionHosts.watchOS of plug-in com.apple.dt.IDEWatchSupportCore
2022-06-04 10:47:51.944 xcodebuild[4259:85660] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionPointIdentifierToBundleIdentifier for extension Xcode.DebuggerFoundation.AppExtensionToBundleIdentifierMap.watchOS of plug-in com.apple.dt.IDEWatchSupportCore
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk

I have pondered whether this should be changed to something else, or perhaps just bite the bullet and add use_xcode yes to the qmake5 PortGroup and be done with it.

But that is for someone else to do, as there will be too much controversy.

adding use_xcode yes to the qtads PortFile fixes it.

[Ken <21211439+kencu@…>]

In 08921402380cc0a06c0b112af75e415062c49add/macports-ports (master):

qtads: add use_xcode yes to fix qmake5 PG issue

see: #65293

[cooljeanius (Eric Gallager)]

OK so if this is about the portgroup in general now, then I guess #65294 should be closed as a dup?

[kencu (Ken)]

it seems like this issue is only affecting the newest systems. older systems (darwin 17, 18, 19) did build qtads without use_xcode yes. More stuff to be figured out in the details, but it appears something changed somewhere.

[kencu (Ken)]

Replying to cooljeanius:

OK so if this is about the portgroup in general now, then I guess #65294 should be closed as a dup?

if adding use_xcode yes fixes that one too, I guess so.

[kencu (Ken)]

there are dozens and dozens of ports (all the ones that use qmake5) that have the exact same issue.

[reneeotten (Renee Otten)]

this is indeed an annoying problem, but it as Ken said it only appears on newer systems... Adding use_xcode yes "fixes" the problem on newer systems, but now also requires users on older systems to have a full XCode installation while there that isn't necessary. That's the reason I've been reluctant to add for ports that report this problem (i.e., 65294 or 65107 or 64884 as I don't consider this the correct fix. Having said that, I also don't have the time or motivation to investigate this more thoroughly and see if there is another way to fix this.

Perhaps if one could identify on which systems this is causing trouble we could add the use_xcode yes conditionally to the qt5 PG - although that might cause other, possible non-reproducible build, issues.

[reneeotten (Renee Otten)]

Replying to kencu:

it seems like this issue is only affecting the newest systems. older systems (darwin 17, 18, 19) did build qtads without use_xcode yes. More stuff to be figured out in the details, but it appears something changed somewhere.

the reason is most likely an update to XCode / command-line tools since I don't think anything in MacPorts has changed in this regard for a while

[kencu (Ken)]

brief experiment on Monterey 12.4 with latest Xcode.

Xcode installed in /Applications:

% /usr/bin/xcrun --sdk macosx12 --show-sdk-path
2022-06-05 11:47:40.220 xcodebuild[40379:537785] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionSentinelHostApplications for extension Xcode.DebuggerFoundation.AppExtensionHosts.watchOS of plug-in com.apple.dt.IDEWatchSupportCore
2022-06-05 11:47:40.220 xcodebuild[40379:537785] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionPointIdentifierToBundleIdentifier for extension Xcode.DebuggerFoundation.AppExtensionToBundleIdentifierMap.watchOS of plug-in com.apple.dt.IDEWatchSupportCore
xcodebuild: error: SDK "macosx12" cannot be located.
2022-06-05 11:47:41.234 xcodebuild[40380:537802] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionSentinelHostApplications for extension Xcode.DebuggerFoundation.AppExtensionHosts.watchOS of plug-in com.apple.dt.IDEWatchSupportCore
2022-06-05 11:47:41.235 xcodebuild[40380:537802] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionPointIdentifierToBundleIdentifier for extension Xcode.DebuggerFoundation.AppExtensionToBundleIdentifierMap.watchOS of plug-in com.apple.dt.IDEWatchSupportCore
xcodebuild: error: SDK "macosx12" cannot be located.
xcrun: error: unable to lookup item 'Path' in SDK 'macosx12'

% /usr/bin/xcrun --sdk macosx --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk

% /usr/bin/xcrun --sdk macosx12  --find ld
2022-06-05 11:46:19.030 xcodebuild[40356:537066] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionSentinelHostApplications for extension Xcode.DebuggerFoundation.AppExtensionHosts.watchOS of plug-in com.apple.dt.IDEWatchSupportCore
2022-06-05 11:46:19.031 xcodebuild[40356:537066] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionPointIdentifierToBundleIdentifier for extension Xcode.DebuggerFoundation.AppExtensionToBundleIdentifierMap.watchOS of plug-in com.apple.dt.IDEWatchSupportCore
xcodebuild: error: SDK "macosx12" cannot be located.
xcrun: error: sh -c '/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -sdk macosx12 -find ld 2> /dev/null' failed with exit code 16384: (null) (errno=No such file or directory)
xcrun: error: unable to find utility "ld", not a developer tool or in PATH

% /usr/bin/xcrun --sdk macosx  --find ld 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld

and with no Xcode installed in /Applications:

% /usr/bin/xcrun --sdk macosx12 --show-sdk-path
xcrun: error: SDK "macosx12" cannot be located
xcrun: error: SDK "macosx12" cannot be located
xcrun: error: unable to lookup item 'Path' in SDK 'macosx12'

% /usr/bin/xcrun --sdk macosx --show-sdk-path 
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

% /usr/bin/xcrun --sdk macosx12  --find ld
xcrun: error: SDK "macosx12" cannot be located
/Library/Developer/CommandLineTools/usr/bin/ld

% /usr/bin/xcrun --sdk macosx  --find ld
/Library/Developer/CommandLineTools/usr/bin/ld

So -- perhaps on systems > darwin19 (ie darwin 20+) we just always call --sdk macosx and skip the always-produces-an-error --sdk macosx${configure.sdk_version} ? After all, as it seems we are not interested in getting into darwin12.1, darwin12.2, etc, this will always error out anyway.

Maybe that would make the use_xcode yes no longer needed, somehow.

[markmentovai (Mark Mentovai)]

This bug was mentioned at ​https://github.com/macports/macports-ports/pull/15136#issuecomment-1159482792.

If you’re experiencing this, can you run

grep -Er '^QMAKE_MAC_SDK\s*=' /opt/local/libexec/qt*

and share the output? Based on the error message reported, it sounds like it’s showing up as macosx11 when it should have been detected as macosx.

[Aaron Madlon-Kay <amake@…>]

In 96ca236731e4c0498f5f7c5ae5deb7b5d7808267/macports-ports (master):

pyotherside: update to 1.6.0, address failure to find SDK

See: #65293

[cooljeanius (Eric Gallager)]

Replying to markmentovai:

This bug was mentioned at ​https://github.com/macports/macports-ports/pull/15136#issuecomment-1159482792.

If you’re experiencing this, can you run

grep -Er '^QMAKE_MAC_SDK\s*=' /opt/local/libexec/qt*

and share the output?

$ grep -Er '^QMAKE_MAC_SDK\s*=' /opt/local/libexec/qt*
grep: /opt/local/libexec/qt4/include/QtCLucene: No such file or directory
grep: /opt/local/libexec/qt4/include/QtDesignerComponents: No such file or directory
grep: /opt/local/libexec/qt4/Library/Frameworks/QtCLucene.framework/Headers: No such file or directory
^C

(it seemed to be hanging, so I killed it)

[mascguy (Christopher Nielsen)]

Add keyword portgroup, to pg-related tickets

[Aaron Madlon-Kay <amake@…>]

In f07c7b4addd2251c6498b9d9d3bf16c7c3ba88fe/macports-ports (master):

qscintilla: work around failure to find SDK

See #65293

[szhorvat (Szabolcs Horvát)]

I see the opposite behaviour: adding use_xcode yes causes "Could not resolve SDK Path", removing this line makes it work.

[szhorvat (Szabolcs Horvát)]

I am removing use_xcode yes in ​https://github.com/macports/macports-ports/pull/20644

[szhorvat (Szabolcs Horvát)]

In 05a310f34e93598a26edb37f4e1cf393ee506d5f/macports-ports (master):

qtads: update to 3.4.0

• update to 3.4.0
• fix "Could not resolve SDK Path" by removing use_xcode, see #65293
• fixes #67687

[herbygillot (Herby Gillot)]

In 4653b5a9a8c26986c4ee2cd72c0c5264403960ca/macports-ports (master):

LibreCAD: update to 2.2.0.2

• assume maintainership
• use the latest Boost available (1.81)
• update librecad-devel to 2.2.1_alpha
• remove "use_xcode yes" to resolve "Could not resolve SDK Path" - #65293

[cooljeanius (Eric Gallager)]

Replying to Aaron Madlon-Kay <amake@…>:

In 96ca236731e4c0498f5f7c5ae5deb7b5d7808267/macports-ports (master):

pyotherside: update to 1.6.0, address failure to find SDK

See: #65293

I'm seeing the failure that this was meant to address with pyotherside again.