This is the mail archive of the libffi-discuss@sources.redhat.com 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 on win32


Eli Barzilay <eli@barzilay.org> writes:

> On May 25, Thomas Heller wrote:
>> 
>> I'm in the process of moving my package (ctypes) to a hacked version
>> of libffi.  It's 99% done, I just need some more time to find and
>> fix the remaining bugs.
>
> Do you have an estimate how long will it be before you have a working
> version?  (Do you think we should grab what you have now and merge
> your updates later, or is it better to wait?)
>
Difficult to say (note that I said I have to *find*, then fix the bugs).
Currently, I've no found but unfixed bugs ;-), and my unittests all run.
I hope to release the next ctypes version next week...

>> <http://cvs.sourceforge.net/viewcvs.py/ctypes/ctypes/source/libffi_msvc/>
>> [...]
>
> Um, so I should take all that and slap it in a simple makefile (or one
> of those workspace, or whatever MSVC calls them (you can see how much
> I use MSVC...))?  Will this produce the right dll for the whole
> libffi?  (Just that I didn't see any makefiles or anything similar.)

Well, Python has distutils and doesn't need a makefile, it's in the
setup script.  The libffi portion is simply the list of source files:
        "source/libffi_msvc/ffi.c",
        "source/libffi_msvc/prep_cif.c",
        "source/libffi_msvc/win32.c",


For ctypes, libffi is not compiled into a dll, the code is statically
compiled into the ctypes 'extension module'.  You could try to do the
same, to create a dll you probably have to add a .def file which lists the
exported functions in the dll. And you have to add types.c, maybe with
this added:

#ifdef _MSC_VER
#define X86
#endif

>
>> I have made a few changes to libffi, the most important is that
>> ffi_call_SYSV() and ffi_call_STDCALL() return an integer now, that
>> is the delta of the stack pointer before and after the call.  This
>> result should be zero, otherwise either the calling convention or
>> the number of parameter (bytes) in the function call is not correct.
>> I need this info for my package.
>
> So assuming I don't use this change (at least not until it propagates
> to the usual libffi), it sounds like I should be able to use this code
> as is with my library, right?

Yes, it seems so.

Thomas

PS: I also have at least one older libffi.dll (including sources) which
someone sent me.  If you want this, I can also mail it to you. IIUC, it
has been compiled with mingw.


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