These include:
- bpo-32726: Provide an additional, more modern macOS installer variant that
supports macOS 10.9+ systems in 64-bit mode only. Upgrade the supplied
third-party libraries to OpenSSL 1.0.2n and SQLite 3.22.0. The 10.9+
installer now supplies its own private copy of Tcl/Tk 8.6.8.
- bpo-24414: Default macOS deployment target is now set by ``configure`` to
the build system's OS version (as is done by Python 3), not ``10.4``;
override with, for example, ``./configure MACOSX_DEPLOYMENT_TARGET=10.4``.
- bpo-19019: All 2.7 macOS installer variants now supply their own version
of ``OpenSSL 1.0.2``; the Apple-supplied SSL libraries and root
certificates are not longer used. The ``Installer Certificate`` command
in ``/Applications/Python 2.7`` may be used to download and install a
default set of root certificates from the third-party ``certifi`` package.
- bpo-11485: python.org macOS Pythons no longer supply a default SDK value
(e.g. ``-isysroot /``) or specific compiler version default (e.g.
``gcc-4.2``) when building extension modules. Use ``CC``, ``SDKROOT``,
and ``DEVELOPER_DIR`` environment variables to override compilers or to
use an SDK. See Apple's ``xcrun`` man page for more info.
- prepare for pending Apple removal of 32-bit support in future macOS release
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r87791 | georg.brandl | 2011-01-06 11:05:26 +0100 (Do, 06 Jan 2011) | 1 line
#10844: update copyright years in Mac plists.
........
framework install of Python in your home directory (on OSX):
$ configure --enable-framework=${HOME}/Library/Frameworks
$ make && make install
Without this patch the framework would get installed just fine,
but 'make install' would try to install the application bundles
and command-line tools outside the user's home, which doesn't work
for non-admin users (and is bad form anyway).
The previous implementation used execv(2) to run the real interpreter, which means that
you cannot use the arch(1) tool to select the architecture you want to use for a
universal build because that only affects the python/pythonw wrapper and not the actual
interpreter.
The new version uses posix_spawnv with a number of OSX-specific options that ensure that
the real interpreter is started using the same CPU architecture as the wrapper, and that
means that 'arch -ppc python' now actually works.
I've also changed the way that the wrapper looks for the framework: it is now linked to
the framework rather than hardcoding the framework path. This should make it easier to
provide pythonw support in tools like virtualenv.
This patch adds a new configure argument on OSX:
--with-universal-archs=[32-bit|64-bit|all]
When used with the --enable-universalsdk option this controls which
CPU architectures are includes in the framework. The default is 32-bit,
meaning i386 and ppc. The most useful alternative is 'all', which includes
all 4 CPU architectures supported by MacOS X (i386, ppc, x86_64 and ppc64).
This includes limited support for the Carbon bindings in 64-bit mode as well,
limited because (a) I haven't done extensive testing and (b) a large portion
of the Carbon API's aren't available in 64-bit mode anyway.
I've also duplicated a feature of Apple's build of python: setting the
environment variable 'ARCHFLAGS' controls the '-arch' flags used for building
extensions using distutils.
This introduces a new configure option: --with-framework-name=NAME
(defaulting to 'Python'). This allows you to install several copies
of the Python framework with different names (such as a normal build
and a debug build).
This adds a new key definition for OSX, which is slightly different from the
classic mac definition.
Also add NEWS item for a couple of bugfixes I added recently.
Ned Deily
Benjamin Peterson
Ned Deily
Georg Brandl
Ronald Oussoren