This change solves two problems encountered by users of the macOS Python Launcher app on recent macOS releases (10.14+):
- The launcher app was no longer able to launch the macOS Terminal.app to run a script.
- Even if Terminal.app was already launched, the launcher app was unable to send an Apple Event to Terminal.app to open and run Python with the desired .py file.
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).
This change is cosmetic only, the "gcc" command in Apple's compiler tools is an alias for "clang" (and using non-system tooling for building the installer is not supported by this script).
Automerge-Triggered-By: GH:ned-deily
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.
- [x] Build OpenSSL 1.1.1k for macOS
- [x] Build OpenSSL 1.1.1k for Windows
I have also updated multissl tester and various CI configurations to use latest OpenSSL. The versions were all over the place.
Signed-off-by: Christian Heimes <christian@python.org>
Automerge-Triggered-By: GH:tiran
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.
build-installer now looks in its directory of source tarballs
for a suitable html tarball of the same version. If so, it
will unpack and use it rather than rebuilding the html format
documentation set from the source repo. This is intended as
a speedup for test builds of the installer. Files names must
be in the same format as produced by the docs build for download,
for example, `python-3.9.0b1-docs-html.tar.bz2`.
Reason: the link `ftp://invisible-island.net/ncurses//5.9/ncurses-5.9-20120616-patch.sh.bz2` is dead, which prevents `Mac/BuildScript/build-installer.py` from completing. Looks like the host of the FTP server was changed to `ftp.invisible-island.net`, thus this proposal.
Signed-off-by: oleg.hoefling <oleg.hoefling@gmail.com>
This reverts commit 0da5466650.
The commit is causing make failures on a FreeBSD buildbot.
Due to the imminent 3.9.0b1 cutoff, revert this commit for
now pending further investigation.
Add support to the configure script for OBJC and OBJCXX command line options so that the macOS builds can use the clang compiler for the macOS-specific Objective C source files. This allows third-party compilers, like GNU gcc, to be used to build the rest of the project since some of the Objective C system header files are not compilable by GNU gcc.
Co-authored-by: Jeffrey Kintscher <websurfer@surf2c.net>
Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
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.
