With recent enough compilers we can build binaries with
LTO/PGO on macOS. This patch enables this when building on
macOS 10.15 or later (Xcode 11 or later).
Narrow search to match contents of SDKs, namely only files in ``/System/Library``,
``/System/IOSSupport``, and ``/usr`` other than ``/usr/local``. Previously,
anything under ``/System`` was assumed to be in an SDK which causes problems
with the new file system layout in 10.15+ where user file systems may appear
to be mounted under ``/System``. Paths in ``/Library`` were also
incorrectly treated as SDK locations.
Co-authored-by: Ned Deily <nad@python.org>
Only complain if the config target is >= 10.3 and the current target is
< 10.3. The check was originally added to ensure that incompatible
LDSHARED flags are not used, because -undefined dynamic_lookup is
used when building for 10.3 and later, and is not supported on older OS
versions. Apart from that, there should be no problem in general
with using an older target.
Authored-by: Joshua Root <jmr@macports.org>
This allows reliably forcing macOS universal2 framework builds
to run under Rosetta 2 Intel-64 emulation on Apple Silicon Macs
if needed for testing or when universal2 wheels are not yet
available.
macOS releases numbering has changed as of macOS 11 Big Sur. Previously, major releases were of the form 10.x, 10.x+1, 10.x+2, etc; as of Big Sur, they are now x, x+1, etc, so, for example, 10.15, 10.15.1, ..., 10.15.7, 11, 11.0.1, 11.1, ..., 12, 12.1, etc. Allow Python to build with single-digit deployment target values. Patch provided by FX Coudert.
On macOS system provided libraries are in a shared library cache
and not at their usual location. This PR teaches distutils to search
in the SDK, even if there was no "-sysroot" argument in
the compiler flags.
As [bpo-38443]() says the error message from configure when specifying --enable-universalsdk with a set of architectures that is not supported by the compiler is not very helpful. This PR explicitly checks if the compiler works and bails out if it doesn't.
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.
Adds a simple check for whether or not the package is being installed in the GUI or using installer on the command line. This addresses an issue where CLI-based software management tools (such as Munki) unexpectedly open Finder windows into a GUI session during installation runs.
_tkinter now builds and links with non-system Tcl and Tk frameworks if they
are installed in /Library/Frameworks as had been the case on older releases
of macOS. If a macOS SDK is explicitly configured, by using ./configure
--enable-universalsdk= or -isysroot, only a Library/Frameworks directory in
the SDK itself is searched. The default behavior can still be overridden with
configure --with-tcltk-includes and --with-tcltk-libs.
Previously, python.org macOS installers did not alter the Current version
symlink in /Library/Frameworks/Python.framework/Versions when installing
a version of Python 3.x, only when installing 2.x. Now that Python 2 is
retired, it's time to change that. This should make it a bit easier
to embed Python 3 into other macOS applications.
On most platforms, the `environ` symbol is accessible everywhere.
In a dylib on OSX, it's not easily accessible, you need to find it with
_NSGetEnviron.
The code was caching the *value* of environ. But a setenv() can change the value,
leaving garbage at the old value. Fix: don't cache the value of environ, just
read it every time.
This changeset increases the default size of the stack
for threads on macOS to the size of the stack
of the main thread and reenables the relevant
recursion test.
Under some conditions the earlier fix for bpo-18075, "Infinite recursion
tests triggering a segfault on Mac OS X", now causes failures on macOS
when attempting to change stack limit with resource.setrlimit
resource.RLIMIT_STACK, like regrtest does when running the test suite.
The reverted change had specified a non-default stack size when linking
the python executable on macOS. As of macOS 10.14.4, the previous
code causes a hard failure when running tests, although similar
failures had been seen under some conditions under some earlier
systems. Reverting the change to the interpreter stack size at link
time helped for release builds but caused some tests to fail when
built --with-pydebug. Try the opposite approach: continue to build
the interpreter with an increased stack size on macOS and remove
the failing setrlimit call in regrtest initialization. This will
definitely avoid the resource.RLIMIT_STACK error and should have
no, or fewer, side effects.
Ned Deily
Ronald Oussoren
Ned Batchelder
Erlend Egeberg Aasland
Pablo Galindo
FX Coudert
David CARLIER
Rick Heil
Krishna Chivukula
Łukasz Langa
Benoit Hudson
Steve Dower
animalize