Python 3.8.10 not built with macOS SDK 11?

[seibert]

While chasing down a pip wheel issue, I noticed that the conda-forge Python 3.8.10 (build 1) package reports the macOS version as 10.16 still. Using Miniforge:

conda create -n py38_test python=3.8
conda activate py38_test
python -c "import platform; print(platform.mac_ver())"

will report

('10.16', ('', '', ''), 'x86_64')

After some digging, it appears that this is caused by building Python 3.8.10 with macOS SDK < 11, in which case macOS will report this fake version number to the process. The recent Python 3.9 packages from conda-forge were built with the macOS 11 SDK and report the true OS version number.

However, it seems that there were commits to the Python 3.8 branch to update the SDK right around the same time as the Python 3.8.10 build: https://github.com/conda-forge/python-feedstock/commits/3.8

I'm not familiar enough with how conda-forge builds are sequenced and uploaded to Anaconda.org to understand exactly what happened here, but would bumping the build number to 2 trigger another build, hopefully with the macOS 11 SDK this time?

[isuruf]

python 3.8 doesn't support building with a new SDK and targetting an older SDK. See python/cpython#26474 (comment)
We pulled 3.8.10 build 1 because of that.

[seibert]

Hmm, that's too bad. Is your patch to upstream to fix this too large, such that conda-forge would not want to include in this build recipe?

The reason I ran into this issue was trying to understand why pip failed to install tensorflow-metal wheels with the conda-forge Python 3.8. The wheels:

https://pypi.org/project/tensorflow-metal/#files

are tagged with macosx_11_0, which pip decides is newer than 10.16, and therefore not eligible to install. The workaround is to set the environment variable SYSTEM_VERSION_COMPAT=0 before calling pip, but I was curious if a fix directly to the conda-forge python package was even an option.

[h-vetinari]

Not sure if this is related, but since 1-2 days, I'm seeing osx-arm fail specifically for python 3.8 (an example; CI run)

  ld: warning: ignoring file /tmp/tmpc54biofq/tmp/tmpc54biofq/source.o, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
  Undefined symbols for architecture arm64:
    "_main", referenced from:
       implicit entry/start for main executable
  ld: symbol(s) not found for architecture arm64
  clang-11: error: linker command failed with exit code 1 (use -v to see invocation)

If so, would it be conceivable to backport python/cpython#26474 despite it not being picked up upstream (due to the branch being frozen for all but security fixes)?

[isuruf]

Definitely not related