[iolib-devel] ECL support

[Stelian Ionescu]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/iolib-devel/attachments/20100529/258ee16c/attachment.sig>