This reverts commit 90d0d20508.
After further consideration, we've decided to remove this workaround:
* It only has an effect if the user has added `gnubin` from Homebrew Coreutils to PATH which is an unsupported setup
* It was intended to be applied only to a few select 3.8 and 3.9 versions that officially support Apple Silicon and only fail with Homebrew Coreutils in PATH because they have `config.*` from a too old version of Autoconf that doesn't support the Arm64 arch -- but
* CPython devs [didn't actually fix the problem in 3.10, either, only in 3.11](https://github.com/pyenv/pyenv/pull/2157#issuecomment-968055387), so we'd need to apply it to all 3.10 releases, too
* users started pushing this workaround into other unrelated branches because they were using the above unsupported setup. See https://github.com/pyenv/pyenv/pull/2190#pullrequestreview-835221952 for discussion.
In my previous work on getting Python 3.6.15 and 3.7.12 to compile on
Apple M1, I backported logic from newer 3.8.x releases to properly find
libffi and related files on macOS.
This regressed compilation on Linux. The include search path was
incomplete, and `ffi.h` could not be found, resulting in `ctypes` being
disabled.
There was a key difference between the old logic and new logic that led
to this regression:
1. In 3.8 and newer, `detect_ctypes()` in `setup.py` took no arguments,
and was expected to access instance variables for the include search
path.
2. In 3.7 and earlier, `detect_ctypes()` took the path as an argument,
and was expected to make use of it.
The backport made use of the instance variables, overriding the provided
include path. These were not equivalent. The one on the instance was not
complete, lacking the necessary directories to find `ffi.h`. Since this
could not be found, `ctypes` support was disabled.
The fix is to simply not overwrite the variables passed to the function,
and resume using them as before.
Fixes#2207
This change ports pyenv and Python patches to 3.7.12 to enable the
`ctypes `and `decimal` modules to compile.
While Python 3.7.12 itself compiles on arm64/M1, both of these modules
fail to compile, due to missing support for locating system libffi and
due to architecture gate-keeping. These issues have been fixed in newer
releases of Python, and in other pyenv patch bundles.
The following patches are provided:
1. `0001-Port-ctypes-and-system-libffi-patches-for-arm64-macO.patch` -
Fixes system `ffi.h`/`libffi` path determination and usage and
enables calling of variadic functions, fixing ctypes support
(consolidated port of existing pyenv patches for 2.7.18 that iterate
on this logic).
2. `0002-bpo-41100-fix-_decimal-for-arm64-Mac-OS-GH-21228.patch` -
Adds arm64 to the list of allowable architectures for the
`decimal` module (port of Python patch introduced in 3.8.10).
This change ports several established patches to the Python 3.6.15
build, enabling compilation on arm64/Apple M1 architectures:
1. `0001-Detect-arm64-in-configure.patch` -
Updates configure to detect arm64 architectures (port of an existing
pyenv patch for 2.7.18).
2. `0002-bpo-36231-Support-building-on-macOS-without-usr-incl.patch` -
Adds macOS SDK root computation logic for determining include paths
(port of existing Python patches introduced in 2.7.17 and 3.7.4).
3. `0003-Fix-macOS-_tkinter-use-of-Tck-Tk-in-Library-Framewor.patch` -
Fixes Tcl/Tk support on macOS (port of an existing pyenv patch
for 2.7.18).
4. `0004-Port-ctypes-and-system-libffi-patches-for-arm64-macO.patch` -
Fixes system `ffi.h`/`libffi` path determination and usage and
enables calling of variadic functions, fixing ctypes support
(consolidated port of existing pyenv patches for 2.7.18 that iterate
on this logic).
5. `0005-BPO-41100-Support-macOS-11-when-building-GH-21113.patch` -
Updates Darwin version checks to handle macOS 11's major version
bump (port of Python patches introduced in 3.7.0 and 3.9.0).
6. `0006-bpo-41100-fix-_decimal-for-arm64-Mac-OS-GH-21228.patch` -
Adds arm64 to the list of allowable architectures for the
`decimal` module (port of Python patch introduced in 3.8.10).
The issue has been resolved in ed38af6409
but the bounty didn't trigger -- allegedly 'cuz it's not a PR.
Bountysource support replied "we're looking" but never did anything
so I'm going to try to trigger it via a dummy PR.
