Ok, finally, I know where the problem lies.
The equivalence ctype <-> libffi seems to be done in the file
Modules/_ctypes/cfield.c
This file builds a table for the equivalence:
#ifdef HAVE_LONG_LONG
{ 'q', q_set, q_get, &ffi_type_slong, q_set_sw, q_get_sw},
{ 'Q', Q_set, Q_get, &ffi_type_ulong, Q_set_sw, Q_get_sw},
#endif
The type ffi_type_[su]long are defined in ffi.h. In the libffi included
with python sources, we have the following:
#define ffi_type_ulong ffi_type_uint64
#define ffi_type_slong ffi_type_sint64
#if LONG_MAX == 2147483647
# if FFI_LONG_LONG_MAX != 9223372036854775807
#error "no 64-bit data type supported"
# endif
#elif LONG_MAX != 9223372036854775807
#error "long size not supported"
#endif
Which set the size of fft_type_[us]long to 8 bytes
But in /usr/include/ffi.h, corresponding to the packaged libffi from
dapper, we have the following:
#if LONG_MAX == 2147483647
# define ffi_type_ulong ffi_type_uint32
# define ffi_type_slong ffi_type_sint32
#elif LONG_MAX == 9223372036854775807
# define ffi_type_ulong ffi_type_uint64
# define ffi_type_slong ffi_type_sint64
#else
#error "long size not supported"
#endif
There is a mixup somewhere between long and long long
--
python2.5 compiled with libffi does not support ctypes 64 bits integer
https://launchpad.net/bugs/72505
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs