On Fri, 2010-05-28 at 20:56 +0400, Nikolay V. Razbegaev wrote: > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > I'm trying to compile recent (b46d84a...: 'Remove =?utf-8?B?wqtTeW50YXg6?= > =?utf-8?B?wrs=?= from file > headers', Thu May 27 17:11:14 2010 +0800) IOLib version with 32 bit > ecl at 32 bit linux host (Archlinux current), but I got some errors > about unknown `:long-long' cffi type. As I can see from cffi sources > using cffi from darcs). But my local ecl version (10.4.1) can operate > with `:long-long' foreign types: > CL-USER> (lisp-implementation-type) > "ECL" > CL-USER> (lisp-implementation-version) > "10.4.1" > CL-USER> *features* > CL-USER> (member :uint64-t *features*) > CL-USER> (uffi:size-of-foreign-type :long-long) > 8 > 8 > CL-USER> (uffi:allocate-foreign-object :unsigned-long-long) > #<foreign :UNSIGNED-LONG-LONG 09674ff8> > CL-USER> (uffi:free-foreign-object *) > ; No value > As I also noticed from the last IOLib commits messages there is some > work on ecl support in IOLib development process. So what's about ecl > support (32 bit)? Is there any way to make IOLib work on it: right > configure flags, right cffi or ecl version or should I just wait and > try to compile it again with right phase of the moon?
I don't know, because I gave up on using ECL. It's too broken for my taste. If you're interested, you'll need to fix cffi and cffi-grovel. Once that is done, iolib should probably work. One thing is sure: waiting is unlikely to be of any use -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
signature.asc
Description: This is a digitally signed message part
_______________________________________________ IOLib-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/iolib-devel
