[Ecls-list] MSVC FFI problems

Tomi Neste tomi.neste at netikka.fi
Sun Dec 30 18:30:52 UTC 2007

Juan Jose Garcia-Ripoll <jjgarcia at users.sourceforge.net> kirjoitti Sun, 30  
Dec 2007 11:42:08 +0200:

> On Dec 30, 2007 2:14 AM, Tomi Neste <tomi.neste at netikka.fi> wrote:
>> Greetings. I'm having some problems with the latest MSVC compiled ECL  
>> and
>> UFFI:
>> 1) When compiling a file with (UFFI:LOAD-FOREIGN-LIBRARY "some.dll") in  
>> it
>> the compiler tries to link with the .dll of the library which won't  
>> work.
>> If the "some.dll" is changed to "some.lib" it compiles but won't load.
>> Everything works fine is I use
> When using the static FFI, that is the one that uses a compiler to
> produce the foreign calls, you should use the *.lib version. You must
> then _compile_ your lisp file and load the compiled version into the
> interpreter. There should be no problem with that.
> If you activate the dynamic FFI, using (setf si:*use-dffi* t), you may
> use the *.dll file directly in interpreted code. The problem with this
> is that function calls are generated by some assembly code which is
> not portable.
>> 2) There is something funny happening when I try to declare foreign
>> functions with :FLOAT arguments. Short example:
>> [...]
>> When I compile and load the files I get seemingly random results from
>> FFI-TEST, with occasional DIVIDE-BY-ZERO. Any clues?
> I assume you are using the compiled version of the FFI (that is
> *use-dffi* = nil) Then you have to provide ECL with a C header with
> the right declarations. This redundancy is used to ensure things
> compile fine, as it is not always enough with the information that
> UFFI supplies. At the top of your lisp file, just add
>    #+ecl (ffi::c-lines "#include \"ffi_test.h\"")
> where ffi_test.h is the header for your foreign file containing all
> function declarations you may need.
> Juanjo

Setting SI:*USE-DFFI* to NIL fixed the loading problem, and adding the  
function prototype with CLINES fixed the floating point problems.
Thanks for the quick response and all the hard work you have done with ECL  


More information about the ecl-devel mailing list