Opened 2 years ago
Last modified 2 months ago
#66113 assigned defect
multiple qt5 ports: configure failure: Project ERROR: Could not resolve SDK Path for 'macosx13' using --show-sdk-path
Reported by: | i0ntempest | Owned by: | i0ntempest |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.8.0 |
Keywords: | Cc: | kencu (Ken), mike142wood | |
Port: | iaito, qBittorrent-qt5 |
Description
These ports still require the configure.sdk_version
workaround to successfully configure. Given the recent fixes on qmake5 pg (used by all of the mentioned ports) and qt5 ports, this should no longer be required. sigil
port only uses qt5 pg and isn't affected by this.
I can see qt5-qtbase: using generic macosx SDK as macosx13 does not exist
in the build log, but I have MacOSX.sdk MacOSX12.3.sdk MacOSX12.sdk MacOSX13.0.sdk MacOSX13.sdk
in /Library/Developer/CommandLineTools/SDKs/
.
Attachments (1)
Change History (8)
Changed 2 years ago by i0ntempest
comment:1 Changed 2 years ago by kencu (Ken)
comment:2 Changed 2 years ago by kencu (Ken)
OK, here's the qmake.stash file that is created by the cmake5 PortGroup.
% cat /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_qBittorrent-qt5/qBittorrent-qt5/work/qbittorrent-qBittorrent-395f70b/.qmake.stash QMAKE_MAC_SDK.macosx.Path = /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk QMAKE_MAC_SDK.macosx.SDKVersion = 13.0 QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_CC = /Library/Developer/CommandLineTools/usr/bin/clang QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_CXX = /Library/Developer/CommandLineTools/usr/bin/clang++ QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_FIX_RPATH = \ /Library/Developer/CommandLineTools/usr/bin/install_name_tool \ -id QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_AR = \ /Library/Developer/CommandLineTools/usr/bin/ar \ cq QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_RANLIB = \ /Library/Developer/CommandLineTools/usr/bin/ranlib \ -s QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_LINK = /Library/Developer/CommandLineTools/usr/bin/clang++ QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_LINK_SHLIB = /Library/Developer/CommandLineTools/usr/bin/clang++ QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_LINK_C = /Library/Developer/CommandLineTools/usr/bin/clang QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_LINK_C_SHLIB = /Library/Developer/CommandLineTools/usr/bin/clang QMAKE_CXX.QT_COMPILER_STDCXX = 199711L QMAKE_CXX.QMAKE_APPLE_CC = 6000 QMAKE_CXX.QMAKE_APPLE_CLANG_MAJOR_VERSION = 14 QMAKE_CXX.QMAKE_APPLE_CLANG_MINOR_VERSION = 0 QMAKE_CXX.QMAKE_APPLE_CLANG_PATCH_VERSION = 0 QMAKE_CXX.QMAKE_GCC_MAJOR_VERSION = 4 QMAKE_CXX.QMAKE_GCC_MINOR_VERSION = 2 QMAKE_CXX.QMAKE_GCC_PATCH_VERSION = 1 QMAKE_CXX.COMPILER_MACROS = \ QT_COMPILER_STDCXX \ QMAKE_APPLE_CC \ QMAKE_APPLE_CLANG_MAJOR_VERSION \ QMAKE_APPLE_CLANG_MINOR_VERSION \ QMAKE_APPLE_CLANG_PATCH_VERSION \ QMAKE_GCC_MAJOR_VERSION \ QMAKE_GCC_MINOR_VERSION \ QMAKE_GCC_PATCH_VERSION QMAKE_CXX.INCDIRS = \ /opt/local/libexec/boost/1.76/include \ /opt/local/include \ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1 \ /Library/Developer/CommandLineTools/usr/lib/clang/14.0.0/include \ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include \ /Library/Developer/CommandLineTools/usr/include QMAKE_CXX.LIBDIRS = \ /opt/local/lib \ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib QMAKE_XCODE_DEVELOPER_PATH = /Library/Developer/CommandLineTools
there has been a proper SDK path found, to the generic SDK, so all that is looking good so far.
comment:3 follow-up: 4 Changed 2 years ago by kencu (Ken)
if I delete the configure.sdk_version
blanking in the Portfile, indeed it fails to properly find and fix the non-working macosx13.
I'm not sure what is going on now.
The block is being run, and previously it worked. However, now it doesn't seem to work. Although it did work when building qt5-qtbase. Heh.
There were some changes to try-catch blocks in MacPorts 2.8.0, no idea exactly what changed or whether it could be related to this.
comment:4 Changed 2 years ago by jmroot (Joshua Root)
Replying to kencu:
There were some changes to try-catch blocks in MacPorts 2.8.0, no idea exactly what changed or whether it could be related to this.
There has been no change to the catch
command, only to the try
command. The latter doesn't appear to be used in these portgroups, but it changed syntax a bit due to adopting Tcl 8.6. Older Tcl versions didn't actually have a try
command, so we provided our own which conformed to TIP 89. However 8.6 ended up adopting somewhat different syntax as per TIP 329.
comment:5 Changed 21 months ago by mike142wood
Cc: | mike142wood added |
---|
comment:6 Changed 20 months ago by kaamui
Trying to rebuild qt5-qtwebengine with proprietary-codecs, I modified the Portfile to add the corresponding option under webengine-kerberos \
(the corresponding option is webengine-proprietary-codecs
). When I do a sudo port build qt5-qtwebengine
, qmake fails with the same message : Could not resolve SDKPath for macosx12.3 using ...
.
Indeed I don't have this SDK. I only have macosx13.1.
Any idea how to fix this ?
On a side note, is editing the portfile and doing sudo port build myport
the correct way to rebuild a port when just editing the Portfile ? I read the documentation and found examples when you try to change source code but not the portfile itself.
Finally, I'm pretty surprised that the option webengine-proprietary-codecs
is not enabled by default, as a lot of web content fails to play without it (PeerTube, Vimeo, etc). This option is enabled by default in official packages on Linux distros. What's preventing MacPorts to do the same ?
comment:7 Changed 2 months ago by i0ntempest
Port: | sqlitebrowser removed |
---|
Yes, I should reword that error message I wrote to something like: