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.
to the libedit emulation of the readline API on OSX 10.5 or later.
This also adds a minimal testsuite for readline to check that the
history manipuation functions have the same interface with both
C libraries.
Tk.framework and build _tkinter only for those
architectures.
This replaces the hardcoded solution that is no
longer valid now that 64-bit capable versions of
Tk are available on OSX.
This is needed because the system linker looks in /Library/Framework before
it looks in /System/Library frameworks. Without this patch _tkinter will
be unusable when it is compiled on a system that has Tk 8.5 installed in
/Library/Frameworks (and the Apple 8.4 install in /System/Library/Frameworks)
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.