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