This is the mail archive of the libffi-discuss@sourceware.org mailing list for the libffi project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libffi - the 10th Anniversary Release


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]