This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: _dyld_shared_cache_contains_path needs SYSTEM_VERSION_COMPAT=0
Type: Stage:
Components: Versions:
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: isuruf, ned.deily, ronaldoussoren
Priority: normal Keywords:

Created on 2021-01-28 06:39 by isuruf, last changed 2022-04-11 14:59 by admin.

Pull Requests
URL Status Linked Edit
PR 24324 closed isuruf, 2021-01-28 06:39
Messages (3)
msg385845 - (view) Author: Isuru Fernando (isuruf) * Date: 2021-01-28 06:39
In macOS Big Sur, if the executable was compiled with MACOSX_DEPLOYMENT_TARGET=10.15
or below, then SYSTEM_VERSION_COMPAT=1 is the default which means that Big Sur
reports itself as 10.16 which in turn means that __builtin_available(macOS 11.0)
will not be triggered.

This can be observed by using the python 3.9.1 universal2 installer and using it on
x86_64 Big Sur or with Rossetta 2 on arm64 Big Sur. (Not an issue with native arm64
as that part is compiled with MACOSX_DEPLOYMENT_TARGET=11.0)

Original issue is that the following returned None.
SYSTEM_VERSION_COMPAT=1 arch -x86_64 /usr/local/bin/python3 -c "from ctypes.util import find_library; print(find_library('AppKit'))"
msg386055 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2021-02-01 04:50
> This can be observed by using the python 3.9.1 universal2 installer and using it on
> x86_64 Big Sur or with Rossetta 2 on arm64 Big Sur.

When not manually setting SYSTEM_VERSION_COMPAT=1,  I cannot reproduce this behavior on current Big Sur (11.1) systems, either x86_64 or arm64 systems, either with the 3.9.1 python.org universal2 installer (which was built on Big Sur with deployment target of 10.9) or by building on 11.1 with MACOSX_DEPLOYMENT_TARGET=10.15:

$ ./configure MACOSX_DEPLOYMENT_TARGET=10.15
$ make
$ ./python -m sysconfig | grep DEPLOYMENT_TARGET
	CONFIG_ARGS = "'MACOSX_DEPLOYMENT_TARGET=10.15'"
	MACOSX_DEPLOYMENT_TARGET = "10.15"
$ ./python -c "from ctypes.util import find_library; print(find_library('AppKit'))"
/System/Library/Frameworks/AppKit.framework/AppKit
$ sw_vers
ProductName:	macOS
ProductVersion:	11.1
BuildVersion:	20C69
$ uname -a
Darwin vana.local 20.2.0 Darwin Kernel Version 20.2.0: Wed Dec  2 20:39:59 PST 2020; root:xnu-7195.60.75~1/RELEASE_X86_64 x86_64

===========
$ arch
arm64
$ arch -arm64 /usr/local/bin/python3.9 -c 'import sys;print(sys.version)'
3.9.1 (v3.9.1:1e5d33e9b9, Dec  7 2020, 12:44:01)
[Clang 12.0.0 (clang-1200.0.32.27)]
$ arch -arm64 /usr/local/bin/python3.9 -c "from ctypes.util import find_library; print(find_library('AppKit'))"
/System/Library/Frameworks/AppKit.framework/AppKit
$ arch -x86_64 /usr/local/bin/python3.9 -c "from ctypes.util import find_library; print(find_library('AppKit'))"
/System/Library/Frameworks/AppKit.framework/AppKit

So, I believe that, while this is an issue when building Python on macOS 10.15 and executing on macOS 11, it is not a problem for the current python.org universal2 installers. Am I missing something?

Further, I believe this issue is essentially a duplicate of Issue42619 which has a draft (work-in-progress) PR to address this in a different way.  We should consider consolidating these issues.

Note that legacy 10.9+ x86_64-only installers *will* see the find_library() failure because they are built on macOS 10.9. A fix for Issue42619 would solve that problem for future "legacy" installers built on 10.9 (although we intend to no longer produce such installers for Python 3.10.)
msg386057 - (view) Author: Isuru Fernando (isuruf) * Date: 2021-02-01 06:09
You are right. I think I may have accidentally used the wrong SDK. Explictly setting `SYSTEM_VERSION_COMPAT=1` is unsupported then?
History
Date User Action Args
2022-04-11 14:59:40adminsetgithub: 87218
2021-02-01 06:09:56isurufsetmessages: + msg386057
2021-02-01 04:50:23ned.deilysetmessages: + msg386055
2021-01-28 06:39:56isurufcreate