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.
Add the Python/dtoa.c file containing the main algorithms;
add corresponding include file and include in Python.h;
include license information for Python/dtoa.c;
add dtoa.c and dtoa.h to Makefile.
of Python (on OSX), and the end result of that is that the combination of
``python-config --ldflags`` and ``python-config --libs`` refers to an actually
existing location.
I've done this in preference to changing python-config to specify
'-framework Python' for linking because that doesn't work when you have multiple
versions of python installed (because '-framework Python' will always link to
the 'Current' version of the framework, without a possibility to specify a
specific version).
clashes with what Python's build target did. Rename the target to 'patchcheck'
to avoid the culture clash.
Closes issue 3758.
Reviewed by Benjamin Peterson.
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.