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
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com
|
