On Nov 21, 2012, at 7:20 PM, Juan Jose Garcia-Ripoll
<jjgar...@users.sourceforge.net> wrote:
> On Wed, Nov 21, 2012 at 10:59 PM, Juan Jose Garcia-Ripoll
> <jjgar...@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)
`(progn
(declaim (inline ,lname))
#-cl-opengl-no-check-error
(defun ,lname ,(mapcar #'first body)
(multiple-value-prog1
(foreign-funcall (,cname :library opengl)
,@(loop for i in body
collect (second i)
collect (first i))
,result-type)
,@(cond
((string= cname "glGetError") ())
((string= cname "glBegin")
`((setf *in-begin* t)))
((string= cname "glEnd")
`((setf *in-begin* nil)
(check-error ',lname)))
(t
`((check-error ',lname))))))
#+cl-opengl-no-check-error
(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:
dlopen (POSIX compliant systems, GNU/Linux, etc.)
shl_load (HP-UX)
LoadLibrary (Win16 and Win32)
load_add_on (BeOS)
NSAddImage or NSLinkModule (Darwin and Mac OS X)
GNU DLD (emulates dynamic linking for static libraries)
libtool's dlpreopen (see see Dlpreopening)
Sylvain
> Juanjo
>
> --
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain)
> http://juanjose.garciaripoll.googlepages.com
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
