Mirko Vukovic | 23 Nov 03:55 2015

what is the length of a long (motivated by GSL2.1 and GSLL)

This message has two audiences:  One the general CFFI group, and second the GSL maintainer.

This is using latest CCL and SBCL on 64-bit Windows 7, and MSYS2 running 64-bit MinGW and its GSL2.0 and 2.1.

Running GSL 2.0 and 2.1 under GSLL resulted in exception violations.  I could eliminate them by specifying the length of an integer as 8 instead of 4 bytes.  

My question has to do with the origin of this specification, since it is derived from CFFI and GSLL, not hard-coded.

Specifically, in GSLL, the following code in init/types.lisp:
(case (cffi:foreign-type-size :long)
  (8 (push :int64 *features*))
  (4 (push :int32 *features*)))

evaluates to 4, pushing :int32 into *features*.  Here is some additional output of cffi:foreign-type-size on my machine:

GSL> (cffi:foreign-type-size :double)
GSL> (cffi:foreign-type-size :long)
GSL> (cffi:foreign-type-size :long-long)
GSL> (cffi:foreign-type-size :int)

This feature eventually makes its way to other code in GSLL.  In the Linear Algebra module, the function make-permutation (in data/permutation.lisp) has this line:
 :element-type '(unsigned-byte #+int64 64 #+int32 32)
 :dimensions (if (typep n 'permutation) (grid:dimensions n) (list n)))))

In my environment element type resulted in unsigned-byte 32.

When I hard-coded my features to :int64 (and unsigned-byte 64), all the exception errors disappeared.

I hope this gives enough background to fix this error (either in my setup, gsll, or cffi).


Luís Oliveira | 11 Nov 18:07 2015

Re: tweak for cffi-grovel::trim-whitespaces?

On Wed, Nov 11, 2015 at 4:39 PM, Mirko Vukovic <mirko.vukovic <at> gmail.com> wrote:
> Hi Louis,
> (I reply to you and not to the forum since you replied to me only - you are
> welcome to forward my reply to the forum)

Oops, my mistake.

> I downloaded from github and got qualified success:
> - At first loading I had to specify the path to ffi.h using cffi::*cc-flags*
> for the compilation to proceed

That's unexpected. Does that mean it failed to execute pkg-config? If
the compilation log doesn't yield any tips, perhaps you could tweak the
pkg-config-cflags definition (in cffi/grovel/grove.lisp) to add some
debugging output and see what's going on there?

> I downloaded from github and got qualified success:
> - At first loading I had to specify the path to ffi.h using cffi::*cc-flags*
> for the compilation to proceed
> - On subsequent loadings, I did not need to do that
> I used ql:quickload to load :cffi-libffi
> Tested on CCL 1-11 and SBCL 1.3.0
> Both Antik and GSLL compile nicely (except for some other minor issues, but
> those are for the antik/gsll forum).
> Thanks,
> Mirko



Luís Oliveira

Mirko Vukovic | 11 Nov 03:53 2015

tweak for cffi-grovel::trim-whitespaces?


This is on 
- 64-bit Windows
- Msys+mingw64 GCC compilation suite
- ccl and/or sbcl (latest Windows version)
- cffi 0.16.1.

I had problems loading cffi-libffi:
- CCL did fine
- SBCL barfed during the grovel phase:
  > Paths returned by pkg-config had a control-M appended to the end

I fixed that by adding \#Return to the list of characters trimmed by cffi-grovel::trim-whitespaces.

With that addition both SBCL and CCL loaded cffi-libffi.


Faré | 17 Sep 05:29 2015

CFFI + asdf bundles

Here is a patch that will make CFFI play better with ASDF bundles.
This allows delivery with a single .so and/or .a file for all the
wrappers in a system, which can be automatically linked into ECL (and
in the future, in SBCL or other implementations, for application

Also, report for a bug, not fixed in the attached patch: compiling,
linking, etc., should be atomic, by using temporary pathnames;
otherwise, there is a race condition when multiple processes try to
execute a script that depends on a CFFI library. Recent-enough ASDF
3.1.2 provides with-temporary-file to help, and 3.1.5 uses it
internally for its own targets, but some implementations still lag
behind with ASDF 3.0.x, and ASDF can't backwards-compatibly use
with-temporary-file for you, so you must use it yourself.

This patch also drops support for ASDF 2 or earlier, because backwards
compatibility is hard, and not necessary: today, all implementations
provide ASDF 3.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The least deviation from truth will be multiplied later.
        — Aristotle
Luís Oliveira | 5 Aug 14:36 2015

CFFI 0.16.0 released


We've just released CFFI 0.16.0!



Luís Oliveira

Victor | 14 Jul 16:37 2015

Using CFFI: dealing with a writeback buffer

Hi all,

I don't know if it is the best place to ask this question, but I'll try it. I am trying to wrap around a following function:

OGRErr OSRExportToProj4(OGRSpatialReferenceH r, char **buff);

This function allocates the string and assigns it to the (char*) pointer passed as buff and then its
contents should be copied into a C string and the obtained pointer released via CPLFree();

So, basically, in C a typical usage would be:

  char *proj = NULL:
  OSRExportToProj4(handle, &proj);
  printf("%s\n", proj);

And the question is: how is this function should be wrapped with CFFI?


-- реклама -----------------------------------------------------------
FREEhost.UA - быстрый и удобный хостинг доступный каждому.

Liam Healy | 11 Jul 22:45 2015

Path discovery and simplification of libffi-unix.lisp

I'm trying to catch up on recent changes made to CFFI with regard to
path discovery with the idea of simplifying code, both in CFFI itself,
and in GSLL (which uses CFFI). The grovel option pkg-config-cflags
seems to permit the elimination of some other code in e.g.
libffi-unix.lisp. With the presence of (pkg-config-cflags "libffi"
:optional t), it seems like these could be eliminated:

(cc-flags "-I/opt/local/include/")

(cc-flags "-I/usr/local/include")

and these

(include "ffi/ffi.h")
(include "ffi.h")

could be replaced with
(include "ffi.h")

Is that correct? Not a darwin or openbsd user so can't test myself.


Luís Oliveira | 29 May 01:14 2015

CFFI 0.15.0 released


I've just released CFFI 0.15.0.



Luís Oliveira

markus | 27 May 23:04 2015

markus.ingvarsson <at> gmail.com has indicated you're a friend. Accept?

I would like to add you as a friend

Mirko Vukovic | 23 May 16:21 2015

How to customize cffi-grovel:*cc*, *cc-flags*?


in order to get GSLL to run on Windows7+CCL+MSYS2+GSL, I needed to customize *cc* and *cc-flags*.  Right now, I do this by modifying the code in grovel.lisp, as for *cc-flags*:

   #+(and windows msys2)
   (list "-I" "E:/msys64/mingw64/lib/libffi-3.2.1/include/"
         "-I" "c:/Users/977315/quicklisp/dists/quicklisp/software/cffi_0.14.0/")

(I prefer not to modify system-wide environment variables on my PC)

I see alternate ways of achieving the same effect:
  1. Write own gsll loader that customizes *cc* and *cc-flags*
  2. Write own cffi-libffi loader that customizes the variables
  3. (somehow) advise gsll or cffi-libffi loaders in my lisp-init files to customize the variables
  4. Modify environment variables for my process.
What is the advised way to do this?  I would prefer 3: in my lisp startup file, I (somehow) write some advice code to asdf that customize *cc* and *cc-flags*.  But I don't know how to do that.

Thank you,


Marshall Mason | 1 May 01:28 2015

Error when passing struct by value

I'm using SBCL version 1.2.4, CFFI version 0.14.0, and libffi version 3.1. I've been trying to pass a struct by value using CFFI and libffi. I'm a newbie to both CFFI and Lisp so I had to piece this together from the manual as well as some of the unit tests that come with CFFI. I'm getting an error that I just can't get past:


The library I'm trying to wrap is libvorbisfile, which decodes Ogg Vorbis files. It has an init function called ov_open_callbacks:

int ov_open_callbacks(void *datasource, OggVorbis_File *vf, const char *initial, long ibytes, ov_callbacks callbacks);

The part it's choking on is the last argument, a struct, passed by value, of callback functions:

typedef struct {
    size_t (*read_func)  (void *ptr, size_t size, size_t nmemb, void *datasource);
    int    (*seek_func)  (void *datasource, ogg_int64_t offset, int whence);
    int    (*close_func) (void *datasource);
    long   (*tell_func)  (void *datasource);
} ov_callbacks;

The library is designed to use one of a few static structs defined in a header file. Since it's defined in the header file and not in libvorbisfile.so, I must create CFFI translation code. There were a lot of other structs I had to wrap with CFFI as well. Here is my code:


Does anyone have any clues about what I'm doing wrong here?

(Regarding my previous email about getting CFFI working on Debian jessie, it turns out the Debian version of cl-alexandria is missing a file and cl-cffi is buggy, so I just added the missing file and installed the CFFI source by hand. Thanks for the response, Fau.)