FreeBSD's P1003.1b semaphore support is highly experimental and
it's disabled by default. Even if a user loads the experimental
kernel module manually, _multiprocessing doesn't work correctly due
to several known incompatibilities around sem_unlink and sem_getvalue,
yet.
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.
directory that is not the source directory (ie, one created using
'/path/to/source/configure'.) Leaves this test very slightly degraded in
that particular case, compared to the build-in-sourcedir case, but that case
isn't a particularly strong test either: neither test the actual path that
will be used after installing. There isn't a particularly good way to test
this, and a poor test beats a failing test.
The bundled libffi copy is now in sync with the recently released
libffi3.0.4 version, apart from some small changes to
Modules/_ctypes/libffi/configure.ac.
I gave up on using libffi3 files on os x.
Instead, static configuration with files from pyobjc is used.
First chapter of the Python 3.0 io framework back port: _fileio
The next step depends on a working bytearray type which itself depends on a backport of the nwe buffer API.
