[Ecls-list] ECL & static symbol references with CFFI

[Sylvain Ageneau]

I think there's an issue with void functions, for example:

(cffi:defcfun ("srand" c-srand) :void '(:unsigned-int))

(defun test-srand ()
  "invokes srand function"
  (cffi:foreign-funcall "srand"))

(test-srand)


;;;
;;; Compiling cffi-test.lisp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
;;; Compiling (CFFI:DEFCFUN ("srand" C-SRAND) ...).
;;; Compiling (DEFUN TEST-SRAND ...).
;;; End of Pass 1.
;;; Emitting code for C-SRAND.
;;; Error:
;;;   in file cffi-test.lisp, position 415
;;;   at (DEFCFUN (srand C-SRAND) ...)
;;;   * Used @(RETURN 0) in a C-INLINE form with 0 output values
;;; Loading "/Users/sylvain/src/LISP/cffi_ecl/cffi-test.fas"



On Nov 22, 2012, at 11:53 AM, Sylvain Ageneau <ageneau at gmail.com> wrote:

> Great!
> 
> I'll try that and report back. Many thanks.
> 
> On Nov 22, 2012, at 11:16 AM, Juan Jose Garcia-Ripoll <juanjose.garciaripoll at gmail.com> wrote:
> 
>> I am attaching a patch for CFFI that allows ECL to build code that does not use dlopen() but rather uses the function symbols as they are know to the C compiler. This is best explained in the code comments, which I reproduce below, and in the example.
>> 
>> The patched CFFI is available at my github account
>> https://github.com/juanjosegarciaripoll/cffi
>> 
>> This is how the example is used
>> 
>> bash-3.2$ ecl -norc
>> ECL (Embeddable Common-Lisp) 12.7.1 (git:e95fa190ccab10a5dcca791658d7d3ff24a77240)
>> Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
>> Copyright (C) 1993 Giuseppe Attardi
>> Copyright (C) 2000 Juan J. Garcia-Ripoll
>> ECL is free software, and you are welcome to redistribute it
>> under certain conditions; see file 'Copyright' for details.
>> Type :h for Help.  
>> Top level in: #<process TOP-LEVEL>.
>> > (load "build")
>> [...]
>> To load "cffi":
>>   Load 1 ASDF system:
>>     cffi
>> ; Loading "cffi"
>> 
>> ;;;
>> ;;; Compiling cffi-test.lisp.
>> ;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
>> ;;;
>> ;;; Compiling (CFFI:DEFCFUN ("sin" C-SINE) ...).
>> ;;; Compiling (DEFUN FF-C-SINE ...).
>> ;;; End of Pass 1.
>> ;;; Emitting code for C-SINE.
>> ;;; Emitting code for FF-C-SINE.
>> ;;; Finished compiling cffi-test.lisp.
>> ;;;
>> ;;; Loading "/Users/jjgarcia/build/cffi-static/cffi-test.fas"
>> 
>>  sin(pi) = 1.22464679914735320720000000000000d-16
>> #P"/Users/jjgarcia/build/cffi-static/build.lisp"
>> 
>> This is the self-explanatory comment
>> 
>> ;;;
>> ;;; ECL allows many ways of calling a foreign function, and also many
>> ;;; ways of finding the pointer associated to a function name. They
>> ;;; depend on whether the FFI relies on libffi or on the C/C++ compiler,
>> ;;; and whether they use the shared library loader to locate symbols
>> ;;; or they are linked by the linker.
>> ;;;
>> ;;;  :DFFI
>> ;;;
>> ;;;  ECL uses libffi to call foreign functions. The only way to find out
>> ;;;  foreign symbols is by loading shared libraries and using dlopen()
>> ;;;  or similar.
>> ;;;
>> ;;;  :DLOPEN
>> ;;;
>> ;;;  ECL compiles FFI code as C/C++ statements. The names are resolved
>> ;;;  at run time by the shared library loader every time the function
>> ;;;  is called
>> ;;;
>> ;;;  :C/C++
>> ;;;
>> ;;;  ECL compiles FFI code as C/C++ statements, but the name resolution
>> ;;;  happens at link time. In this case you have to tell the ECL
>> ;;;  compiler which are the right ld-flags (c:*ld-flags*) to link in
>> ;;;  the library.
>> ;;;
>> (defvar *cffi-ecl-method*
>>   #+dffi :dffi
>>   #+(and dlopen (not dffi)) :dlopen
>>   #-(or dffi dlopen) :c/c++
>>   "The type of code that CFFI generates for ECL: :DFFI when using the
>> dynamical foreign function interface; :DLOPEN when using C code and
>> dynamical references to symbols; :C/C++ for C/C++ code with static
>> references to symbols.")
>> 
>> 
>> -- 
>> Instituto de Física Fundamental, CSIC
>> c/ Serrano, 113b, Madrid 28006 (Spain) 
>> http://juanjose.garciaripoll.googlepages.com
>> <build.lisp><cffi-test.lisp><0001-Allow-the-ECL-backend-to-support-different-combinati.patch>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20121122/8e63a40a/attachment.html>