[issue43052] _dyld_shared_cache_contains_path needs SYSTEM_VERSION_COMPAT=0

[Isuru Fernando]

Isuru Fernando  added the comment:

You are right. I think I may have accidentally used the wrong SDK. Explictly 
setting `SYSTEM_VERSION_COMPAT=1` is unsupported then?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43052] _dyld_shared_cache_contains_path needs SYSTEM_VERSION_COMPAT=0

[Ned Deily]

Ned Deily  added the comment:

> 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.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43052] _dyld_shared_cache_contains_path needs SYSTEM_VERSION_COMPAT=0

[Isuru Fernando]

New submission from Isuru Fernando :

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'))"

--
messages: 385845
nosy: isuruf, ned.deily, ronaldoussoren
priority: normal
pull_requests: 23185
severity: normal
status: open
title: _dyld_shared_cache_contains_path needs SYSTEM_VERSION_COMPAT=0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com