The ctypes sources contain the source code for libffi, in Modules/_ctypes/libffi. These sources were pulled from GCC cvs some time ago, and a new configure system was written by Perky iirc.
Now, it seems that these sources are showing their age and a newer libffi version should be used instead. There are issues on certain platforms like mips64, arm, armeabi; also on other systems to correctly use the c_longdouble data type that I added recently. See also http://bugs.python.org/issue1292. Pythons configure command has a --with-system-ffi option that, if specified, uses a system installed libffi package (if present). By default, the bundled sources are used. The cleanest way to fix this problem probably would be to remove the outdated libffi sources from Python svn (in trunk and py3k), and require a system installed libffi for building ctypes. However, I have no idea if there are libffi packages available for systems like solaris, BSD, or OS X (to name a few that come to mind). Another way would be to leave the sources in place, and only use them when no system libffi installation is present - in other words to change the default of the --with-system-ffi option. Matthias Klose has already committed a change to configure.in that sets --with-system-ffi="yes" for Linux/arm* systems. This would be a third way: do this for all systems that require newer libffi. Any thoughts? Thanks, Thomas PS: As a test, I changed setup.py (in branches/ctypes-branch) so that always a system installed libffi is used, and manually triggered the build on the bots that failed or even crashed before: ppc Debian unstable, and S-390 Debian. PPS: The above does not apply for Windows; the windows libffi suorces work fine and are in different subdirectories. Also, configure is not used on Windows. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
