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.
properly, and use this to skip test_multiprocessing on platforms
where sem_open raises a signal. This should fix some FreeBSD buildbot
failures for test_multiprocessing.
On MacOSX 10.6 the CoreFoundation framework must be initialized on the main
thread, the constructor function in that framework will cause an SIGABRT when
it is called on any other thread.
Because a number of extension link (indirectly) to CoreFoundation and the
Python core itself didn't the interpreter crashed when importing some
extensions, such as _locale, on a secondary thread.
This fix ensures that Python is linked to CoreFoundation on OSX, which results
in the CoreFoundation constructor being called when Python is loaded. This
does not require code changes.
- add double endianness detection to configure script
- add configure-time check to see whether we can use inline
assembly to get and set x87 control word in configure script
- add functions to get and set x87 control word in Python/pymath.c
- add pyport.h logic to determine whether it's safe to use the
short float repr or not
to that README file with some explanation.
* Be more strict in the configure script: complain loudly when the user has
specified invalid combinations of OSX-specific configure arguments.
The error message refers to the Mac/README file for more information.
issue #2937. This information can be helpful for diagnosing platform-
specific problems in math and cmath. The result of the test also
serves as a fairly reliable indicator of whether the x87 floating-point
instructions (as opposed to SSE2) are in use on Intel x86/x86_64 systems.