This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: libffi - the 10th Anniversary Release
- From: Thomas Heller <theller at ctypes dot org>
- To: libffi-discuss at sourceware dot org
- Cc: Dalibor Topic <robilad at kaffe dot org>, Tom Tromey <tromey at redhat dot com>, Anthony Green <green at redhat dot com>, theller at python dot net
- Date: Tue, 29 Jan 2008 20:12:47 +0100
- Subject: Re: libffi - the 10th Anniversary Release
- References: <479F1FCB.5060002@redhat.com> <m3d4rkg0ay.fsf@fleche.redhat.com> <479F4C46.4020406@kaffe.org>
Dalibor Topic schrieb:
> Tom Tromey wrote:
>> Dalibor also pointed out this patch:
>>
>> http://svn.python.org/view/ctypes/trunk/ctypes/win64.diff?rev=53398&view=auto
>>
>> This adds Win64 support.
>>
>> Tom
>>
> As ctypes is theller's code, and he seems to have a bunch of different
> libffi patches stuck away in branches,
> I figured it's best to ping theller himself what to merge. I'd love to
> see the arm-wince stuff go in, but I have
> nothing to test it myself.
Well, the libffi_msvc directory is a branch of the libffi sources, adapted
so that they can be compiled with the MS compilers. Both for win32/x86 and
win64/amd64. Both the cdecl and stdcall calling conventions are supported,
also for closures. The ffi_call function has been changed to return an integer
which informs about the stack pointer difference before and after the function call;
this is to detect wrong calling convention or wrong number of parameters passed (in stdcall).
The libffi_asm_wince directory is for MS compilers and windows ce/arm, with
closure support.
The changes to the libffi directory that I remember are these:
- New configure system (this was not written by me). The goal was
to have no GPL'd files in the Python svn repo. Also the libffi sources
are not compiled into a shared library, instead they are linked into
the Python ctypes extension that uses it.
- We changed the libffi sources to use proper function prototypes
since we have a zero-compiler-warning policy. For example:
-extern void ffi_call_osf(void *, unsigned long, unsigned, void *, void (*)())
+extern void ffi_call_osf(void *, unsigned long, unsigned, void *, void (*)(void))
Is there a reason to keep these 'void (*)()' constructs?
- Remove live_support (for OS X 10.3, IIRC), as already mentioned:
http://svn.python.org/view/python/trunk/Modules/_ctypes/libffi/src/powerpc/darwin_closure.S?rev=43609&r1=42928&r2=43609
- A fix for FreeBSD/x86:
http://svn.python.org/view/python/trunk/Modules/_ctypes/libffi/src/x86/ffi.c?rev=45440&r1=43593&r2=45440&diff_format=u
- Add .note.GNU-stack to sysv.S so that ctypes isn't considered as requiring executable stacks.
http://svn.python.org/view/python/trunk/Modules/_ctypes/libffi/src/x86/sysv.S?rev=52418&r1=42928&r2=52418
The directories I mentioned above are all relative to
(for svn) http://svn.python.org/view/python/trunk/Modules/_ctypes/
(for viewcvs) http://svn.python.org/projects/python/trunk/Modules/_ctypes/
Thanks,
Thomas