py310-pyqt5-webengine: xcrun: error: SDK "macosx10.13" cannot be located

[RivetBenoit (Benoit Rivet)]

I tried to upgrade py39-spyder, which fails trying to build py39-pyqt5-webengine. Same failure when trying to install py310-pyqt5-webengine. MacPorts reports the following :

--->  Attempting to fetch py310-pyqt5-webengine-5.15.5_0.darwin_17.x86_64.tbz2 from http://mse.uk.packages.macports.org/py310-pyqt5-webengine
--->  Fetching distfiles for py310-pyqt5-webengine
--->  Verifying checksums for py310-pyqt5-webengine
--->  Extracting py310-pyqt5-webengine
--->  Configuring py310-pyqt5-webengine
xcrun: error: SDK "macosx10.13" cannot be located
--->  Building py310-pyqt5-webengine
Error: Failed to build py310-pyqt5-webengine: command execution failed

py39-pyqt5-webengine used to build before on High Sierra since the command port outdated yields :

The following installed ports are outdated:
py39-pyqt5-webengine           5.15.4_1 < 5.15.5_0       
py39-spyder                    5.1.5_1 < 5.3.0_0  

[RivetBenoit (Benoit Rivet)]

Full log report from /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-pyqt5-webengine/py310-pyqt5-webengine/main.log

[jmroot (Joshua Root)]

The log shows a different error:

ModuleNotFoundError: No module named 'ply'

That looks like a missing dependency in py310-sip.

[reneeotten (Renee Otten)]

In 671be06eb6695666d12e397187000e3f08b1bfd2/macports-ports (master):

py-sip: add missing py-ply depdendency

Closes: #65107

[RivetBenoit (Benoit Rivet)]

After installing py310-ply, the build fails again, with the following warning in the main.log file :

:info:build Project ERROR: Could not resolve SDK Path for 'macosx10.13' using --show-sdk-path

For your information, the command xcrun --show-sdk-path yields :

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

[RivetBenoit (Benoit Rivet)]

Log file after installing py310-ply

[reneeotten (Renee Otten)]

I don't know... this type of error :info:build Project ERROR: Could not resolve SDK Path for 'macosx10.13' using --show-sdk-path

shows up occasionally on some systems (e.g., 62309) for ports that are related to Qt5. Unfortunately, I don't think we have ever gotten to the bottom of this... it could be related to whether you have a full XCode installation or only the CLT, which one applies to you?

If you want to help and troubleshoot this (I don't have an older macOS and it works for me locally) then you could try to add use_xcode yes to the Portfile, try to build it again and report back here. Assuming that you don't have a ​local Portfile repository [if you do, you likely now your way around Portfiles and don't need these instructions ;)] you can do this by opening a terminal and typing:

sudo vi `port file py-pyqt5-webengine`

in that file you add the use_xcode yes, save the file and regenerate the portindex and do the usual clean and install:

portindex && sudo port clean --all subportof:py-pyqt5-webengine && sudo port -dv install py310-pyqt5-webengine

[RivetBenoit (Benoit Rivet)]

1. I have both a full Xcode installation and command line tools

>>> xcodebuild -version
Xcode 10.1
Build version 10B61

2. Adding use_xcode yes in /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/python/py-pyqt5-webengine/Portfile and so on enables me to build and install py310-pyqt5-webengine.

3. Thank you :-)

[mouse07410 (Mouse)]

IMHO, MacPorts should be satisfied when /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk is found, and not fuss about the numbers.

[reneeotten (Renee Otten)]

Replying to mouse07410:

IMHO, MacPorts should be satisfied when /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk is found, and not fuss about the numbers.

well... if you know how to solve this in a general manner, please let us know.

[kencu (Ken)]

On systems that don't have the SDK installed into "/", which is all newer systems, MacPorts base is set to first of all look for the SDK that exactly matches the build system, for maximum compatibility between the build SDK and the features of the system. This causes the fewest build issues.

If there is no such SDK, then it will fall back to use a generic MacOSX.sdk if that exists.

qt5, qmake 5, the qt5 portgroup, or the qmake 5 portgroup, or some combination of these, does not seem to be properly following this plan, does not seem to be using the SDK MacPorts requests it to use, and qt5 does it's own search for an SDK that does not always work out on our myriad of build systems.

It is plenty hard to debug this, as it is all done inside configure shell scripts, etc, in the qt5 build. You need to throw in echo lines, etc, to make any progress, and it is hard.

I and others stumbled across using "use_xcode yes" as a workaround that often seems to fix the build. What this exactly does is unclear. It may in fact just follow a different path in the qt5 PortGroup, which is possibly where the error needs fixing.

But as "use_xcode yes" works, and I have xcode installed on every system, I stopped spending any more of my time on this particular headache.

If someone wants to sort it out, have at it, and PR the proper fix once you find it!

[mouse07410 (Mouse)]

MacPorts base is set to first of all look for the SDK that exactly matches the build system, for maximum compatibility between the build SDK and the features of the system. This causes the fewest build issues

You've dealt with a lot more (and more diverse) builds than I - so, you probably know better. But still, what you said does not seem right.

If there is no such SDK, then it will fall back to use a generic MacOSX.sdk if that exists.

If either Xcode or CLT is installed, it is impossible for MacOSX.sdk to not exist, AFAIK.

I still think that using MacOSX.sdk when it's available is the best course on all the platforms - with a possible exception for cross-compilation (like, building M1 code on x86_64 - which I personally think is stupid wrong).

[kencu (Ken)]

Replying to mouse07410:

I still think that using MacOSX.sdk when it's available is the best course on all the platforms.

I'll try to explain why that doesn't work as well as you would hope it would. Please bear with me for a moment.

Let's aay you are on MacOSX12.3. You install the latest version of Xcode, and it happens to come with MacOSX13.0.sdk which being the latest SDK is then symlinked by Apple to MacOSX.sdk. This is a very typical situation.

So you build against MacOSX.sdk, which is MacOSX13.0.sdk. Your configure scripts test for things using the headers in that SDK, and this finds certain features in the headers as defined, certain functions are available, etc.

But -- those functions are not actually in your system, which is MacOSX12.3. Ultimately, your build either fails to link, or if it links, it fails to run. You're DOA.

Now - properly written software, which always does the right thing, has less of this issue. The build will actually test that things link, or maybe even test that they run, rather than just test to see if they are defined.

Software written with Apple specifically in mind will possibly test for the function at runtime using one of several approaches, and use a fallback code path if the function is not available.

But the vast majority of software, especially free open source software, is not written to that standard, and it kacks.

[mouse07410 (Mouse)]

So you build against MacOSX.sdk, which is MacOSX13.0.sdk . . . But -- those functions are not actually in your system, which is MacOSX12.3. Ultimately, your build either fails to link, or if it links, it fails to run. You're DOA.

I understand your explanation. All I can say in response is that in all the years of building on Mac software (that worked! ;) - and most of it with Xcode Clang - I never encountered such a situation myself. And in 99.99% of cases, software performed no specific tests (beyond what, e.g., autoconf does).

One thing though:

Your configure scripts test for things using the headers in that SDK, and this finds certain features in the headers as defined, certain functions are available, etc.

AFAIK, autoconf and such determine what functions to test for using available headers - but then try to actually compile and link test-binary to ensure the function is really there. Relying merely on what's in the header doesn't sound like a good idea.

[kencu (Ken)]

Anyway, you now have the skinny on why MacPorts has always insisted, as much as possible, on the SDK that matches the system.

This goes back to the very beginning, and it won’t be changing unless something really major happens that forces it to change.

You are always free to set up your own systems however you want to, of course!

[mf2k (Frank Schima)]

Echoing the above, adding the following line to the Portfile fixes this for me with Xcode 13.4.1 on Monterey:

use_xcode yes

[wcvinyard (Bill)]

macbook pro 16 -inch 2021 M1 Max Memory 64GB Monterey 12.4

MacPorts 2.7.2

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

xcodebuild -version Xcode 13.4.1 Build version 13F100

use_xcode yes worked for me as well

[Aaron Madlon-Kay <amake@…>]

In 768d77c6a91e6f6d47e12ff8726b964ed6b6f0cd/macports-ports (master):

py-pyqt5-webengine: fix build due to failure to find SDK

See: #65107

[Aaron Madlon-Kay <amake@…>]

In 4ddd2125048e73aaf482f7d423bc1ef2e39f1761/macports-ports (master):

yubico-authenticator: address failure to find SDK

See: #65107