Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
bpo-41100: Support macOS 11 and Apple Silicon #22855
Conversation
We should consider just dropping support for macOS 10.4 here to simplify the code.
This is support for ctypes on macOS/arm64 based on PR 21249 by Lawrence D'Anna (Apple). Changes: - changed __builtin_available tests from 11.0 to 10.15 - added test to setup.py for ffi_closure_alloc and use that in malloc_closure.c - Minor change in the code path for ffi_prep_closure_var (coding style change)
The preprocessor guard in the old version doesn't work, and isn't really needed (10.4 only supported 32-bit code where unsigned long is the same as uint32_t).
This also adds an option to stop building after compiling the 3th-party dependencies, as well as a script for archiving those dependencies. This makes it easier to work on the build. There are three changes to build-installer.py related to universal2 support: 1. Add 'universal2' information to build-installer.py; 2. Building OpenSSL for arm64 requires a patch at this time; 3. For some reason I had to patch the Tcl build to avoid a build error.
Needed because my previous workaround doesn't work anymore. This uses a private API, that should be made public later...
- __builtin_available is not present in the compiler, fall back to the ancient way of testing if a symbol is usable. - Logic error code in pytime.c resulted in a compile error.
…oren/cpython into macos11-deploy-earlier-branch
The tests are not entirely done yet, and something similar needs to be done for the time module.
…on isn't present. I don't particularly like the code duplication, but this code should be pretty stable.
|
Thanks @ronaldoussoren for the PR |
|
Sorry @ronaldoussoren, I had trouble checking out the |
Co-authored-by: Lawrence D’Anna <lawrence_danna@apple.com> * Add support for macOS 11 and Apple Silicon (aka arm64) As a side effect of this work use the system copy of libffi on macOS, and remove the vendored copy * Support building on recent versions of macOS while deploying to older versions This allows building installers on macOS 11 while still supporting macOS 10.9.
Backport of commit 4176193 to 3.9: ___ Co-authored-by: Lawrence D’Anna <lawrence_danna@apple.com> * Add support for macOS 11 and Apple Silicon (aka arm64) As a side effect of this work use the system copy of libffi on macOS, and remove the vendored copy * Support building on recent versions of macOS while deploying to older versions This allows building installers on macOS 11 while still supporting macOS 10.9.
Backport of commit 4176193 to 3.9: ___ Co-authored-by: Lawrence D’Anna <lawrence_danna@apple.com> * Add support for macOS 11 and Apple Silicon (aka arm64) As a side effect of this work use the system copy of libffi on macOS, and remove the vendored copy * Support building on recent versions of macOS while deploying to older versions This allows building installers on macOS 11 while still supporting macOS 10.9.
Backport of commit 4176193 to 3.9: ___ Co-authored-by: Lawrence D’Anna <lawrence_danna@apple.com> * Add support for macOS 11 and Apple Silicon (aka arm64) As a side effect of this work use the system copy of libffi on macOS, and remove the vendored copy * Support building on recent versions of macOS while deploying to older versions This allows building installers on macOS 11 while still supporting macOS 10.9.
(Apple Silicon being their aarch64 platform.) Patches consist of: - Upstream work: python/cpython#22855 - Fix for setup.py to find libbz2.tbd and libz.tbd now that with the shared library cache there's nothing in /usr/lib. See: https://bugs.python.org/issue41116 - Addition of __arch64__ case to fix _decimal module. A very similar fix has since been committed upstream.
|
Is the plan still to backport this (or a part of this) to Python 3.8? We are not yet planning to migrate to Python 3.9 and the ability to build for Apple Silicon being merged thus available downlevel would be helpful (I also wouldn't expect any guarantee of support, I'm thinking of this as a "you can build for this configuration but you're on your own" situation). |
|
@maxbelanger, sorry being out of the loop, though I hope this clarification may be useful to others who land on this ticket. |
|
@dimaqq sorry, that wasn't clear. I was referring to Dropbox; we ship Python as part of our client application on macOS. |
Backport of commit 4176193 to 3.9: ___ Co-authored-by: Lawrence D’Anna <lawrence_danna@apple.com> * Add support for macOS 11 and Apple Silicon (aka arm64) As a side effect of this work use the system copy of libffi on macOS, and remove the vendored copy * Support building on recent versions of macOS while deploying to older versions This allows building installers on macOS 11 while still supporting macOS 10.9.
Backport of commit 4176193 to 3.9: ___ Co-authored-by: Lawrence D’Anna <lawrence_danna@apple.com> * Add support for macOS 11 and Apple Silicon (aka arm64) As a side effect of this work use the system copy of libffi on macOS, and remove the vendored copy * Support building on recent versions of macOS while deploying to older versions This allows building installers on macOS 11 while still supporting macOS 10.9.
Backport of commit 4176193 to 3.9: ___ Co-authored-by: Lawrence D’Anna <lawrence_danna@apple.com> * Add support for macOS 11 and Apple Silicon (aka arm64) As a side effect of this work use the system copy of libffi on macOS, and remove the vendored copy * Support building on recent versions of macOS while deploying to older versions This allows building installers on macOS 11 while still supporting macOS 10.9.
Backport of commit 4176193 to 3.9: ___ Co-authored-by: Lawrence D’Anna <lawrence_danna@apple.com> * Add support for macOS 11 and Apple Silicon (aka arm64) As a side effect of this work use the system copy of libffi on macOS, and remove the vendored copy * Support building on recent versions of macOS while deploying to older versions This allows building installers on macOS 11 while still supporting macOS 10.9.
Co-authored-by: Lawrence D’Anna <lawrence_danna@apple.com> * Add support for macOS 11 and Apple Silicon (aka arm64) As a side effect of this work use the system copy of libffi on macOS, and remove the vendored copy * Support building on recent versions of macOS while deploying to older versions This allows building installers on macOS 11 while still supporting macOS 10.9.. (cherry picked from commit 4176193) Co-authored-by: Ronald Oussoren <ronaldoussoren@mac.com>
|
GH-23295 is a backport of this pull request to the 3.9 branch. |
|
@maxbelanger per the tagging/metadata in the issue at https://bugs.python.org/issue41100, this will likely be ported to Python 3.8 as well. I don't know who will do it, but this is an educated guess based on how CPython's bug tracker works. Given how the 3.9 backport needed to be done manually, I imagine the 3.8 backport needs to be done as well. |
|
Porting to 3.8 is next on our list. |
(Apple Silicon being their aarch64 platform.) This is backport of the same in lang/python39. Only minor changes were needed. Patches consist of: - Upstream work: python/cpython#22855 - Fix for setup.py to find libbz2.tbd and libz.tbd now that with the shared library cache there's nothing in /usr/lib. See: https://bugs.python.org/issue41116 - Addition of __arch64__ case to fix _decimal module. A very similar fix has since been committed upstream.
(Apple Silicon being their aarch64 platform.) This is backport of the same in lang/python39 and lang/python38. Some parts weren't applicable in 3.7. The setup.py script needed some work on the ffi code. Otherwise, minor changes. Patches consist of: - Upstream work: python/cpython#22855 - Fix for setup.py to find libbz2.tbd and libz.tbd now that with the shared library cache there's nothing in /usr/lib. See: https://bugs.python.org/issue41116 - Addition of __arch64__ case to fix _decimal module. A very similar fix has since been committed upstream.
This merges my other two PRs, and improves on the PR that implements support for older macOS versions.
on systems that don't support his.
https://bugs.python.org/issue41100