On Nov 21, 2012, at 7:20 PM, Juan Jose Garcia-Ripoll <jjgarcia@users.sourceforge.net> wrote:

On Wed, Nov 21, 2012 at 10:59 PM, Juan Jose Garcia-Ripoll <jjgarcia@users.sourceforge.net> wrote:
I've been struggling with trying to use cffi based libraries with ECL on iOS which doesn't allow dlopening dynamic libraries (so ECL has to be compiled with --disable-shared).

Hmm, is it really that difficult? CFFI is quite an uncomfortable beast to work with, since it definitely assumes that libraries have to be loaded, etc, but it could be easily fixed to work with statically linked libraries by

1) Intercepting the library loading functions
2) Ensuring DFFI is not used.

If you do 1) and 2), then CFFI will work with statically linked libraries. Would this help you somehow?

Ah ok, I hadn't done 2) because I assumed that libraries that used cffi:foreign-funcall depended on being able to use dlsym to resolve the foreign symbols at runtime but I see cffi also has a non dffi implementation. 

I'm using this to port cl-opengl to iOS/OpenGLES and while I got it to build I had the issue that any calls to a cl-opengl function failed to call the corresponding C function (because si:find-foreign-symbol wouldn't find the symbol).

The macro they use to generate the callbacks (by parsing an OpenGL spec file) is:

(defmacro defglfun ((cname lname) result-type &body body)
     (declaim (inline ,lname))
       (defun ,lname ,(mapcar #'first body)
             (foreign-funcall (,cname :library opengl)
                              ,@(loop for i in body
                                   collect (second i)
                                   collect (first i))
              ((string= cname "glGetError") ())
              ((string= cname "glBegin")
               `((setf *in-begin* t)))
              ((string= cname "glEnd")
               `((setf *in-begin* nil)
                 (check-error ',lname)))
               `((check-error ',lname))))))
     (defcfun (,cname ,lname :library opengl) ,result-type ,@body)))

Should that code work in a non dffi ecl build? I don't get how the linker will know the GL functions need to be referenced in the executable. Or do I need to replace that by calls to c-inline?

Note: I am not rejecting your ltdl patches. I would just need to know whether they solve  problem or whether there are better approaches. It would also be interesting to have the patch without including ltdl in the package (only libraries which are needed for Windows's MSVC are included in ECL).

Well I guess this patch is rather pointless then since it's main intended purpose was to use cffi on static builds :) Maybe if used as a general dlopen/dlsym replacement ltdl could be to used to remove some of the platform specific code in libraries.d (I wouldn't feel very confident implementing that though). From the doc:

libltdl supports currently the following dynamic linking mechanisms:



Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)