Hi Zach,

On Sat, 20 Jun 2009, Zach wrote:

Looks like it can't find ffi.h.  I suppose that you should be able to point it to the correct location by changing the the form in the asd file from

(cffi-grovel:grovel-file "libffi" :pathname #+unix "libffi-unix")

to

(cffi-grovel:grovel-file "libffi" :pathname #+unix "libffi-unix" :cc-flags "-I/path/to/ffi/headers")

Thanks that fixed the problem.

I know this since I have for a long time had to do this for any system that uses cffi-grovel, since I often have libraries in only somewhat standard places under OS X.  Since you are using common-lisp-controller, that means you are using a Linux, right?  If so, this should really work out of the box for you.  Whether the shortcoming is with FSBV or CFFI-GROVEL, I don't know (for instance, it would be nice if CFFI-GROVEL took a default cc-flags from the CFLAGS environment variable or something).

I am using Linux which is why I was a bit confused as it should work and was working until recently. Either way it is working now so thanks again.

Jason

On Sat, Jun 20, 2009 at 10:07 AM, Jason Nielsen jdn@math.carleton.ca wrote: Hello all,

  I just git pulled all the new goodness in gsll, fsbv etc. but am getting
  error messages building fsbv:

  ;
  /var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/init.fasl
  written
  ; compilation finished in 0:00:00.004
  ; cc -m64 -fPIC -o
  /var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix
  /var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c
  unhandled SIMPLE-ERROR in thread #<SB-THREAD:THREAD "initial thread"
  RUNNING {10029DDD71}>:
    External process exited with code 1.
  Command was: "cc" "-m64" "-fPIC" "-o"
  "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix"
  "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c"
  Output was:
  "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c",
  line 7: cannot find include file: <ffi.h>
  "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c",
  line 40: undefined symbol: FFI_OK
  "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c",
  line 45: undefined symbol: FFI_BAD_TYPEDEF
  "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c",
  line 50: undefined symbol: FFI_BAD_ABI
  "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c",
  line 61: undefined symbol: FFI_DEFAULT_ABI
  "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c",
  line 66: undefined symbol: FFI_SYSV
  "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c",
  line 71: undefined symbol: FFI_UNIX64
  "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c",
  line 79: undefined symbol: ffi_abi
  "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c",
  line 126: incomplete struct/union/enum _ffi_type: sizeof()
  "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c",
  line 131: undefined struct/union member: size
  "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c",
  line 136: undefined struct/union member: alignment
  "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c",
  line 141: undefined struct/union member: type
  "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c",
  line 146: undefined struct/union member: elements
  "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c",
  line 397: warning: implicit function declaration: memset
  cc: acomp failed for
  /var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c

  I have cffi 0.10.5 installed and its test suite passes.  I also have
  libffi-dev installed in the usual place so I'm a bit confused.

  Cheers,
  Jason

  _______________________________________________
  Gsll-devel mailing list
  Gsll-devel@common-lisp.net
  http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel

On Tue, 23 Jun 2009, Liam Healy wrote:

Not so fast... I'd like to try to come up with a solution that works for the major OSes/distrbutions when things are installed in standard places. The :cc-flags is a hack to add a new path; why is it necessary?

What version of Linux are you using? What library(ies) are you having problems with? Are they installed in the system-standard places? What files are in the "wrong" place? Where are they?

As for me, I use Debian. Everything is installed from the distribution, so packages like libffi-dev place the .h files in the standard places. For example,

dpkg -L libffi-dev ... /usr/include/x86_64-linux-gnu/ffi.h /usr/include/x86_64-linux-gnu/ffitarget.h ...

I put (include "ffi.h") in libffi-unix.lisp, and that works. My understanding is that almost all distributions conform to the FHS http://www.pathname.com/fhs/ and so this should work on all these distributions. If that is not the case, I would like to know why. I do not know how to provide alternative .h paths, but I can ask on the cffi-grovel list if necessary. I hope it is not necessary; the preferred solution is to (include ...) the files in the right place.

Liam

I am running Ubuntu 8.10 on a dual quad core 64bit system. Until recently I did not have to do any -I magic to include headers but I do now and you can use the date stamp of my original post as a time-line since before that I had no trouble with compiling vanilla git pulls using sbcl v1.0.27. In truth I use a heavily tuned system as I do rather computationally intensive stuff (this is my test/debug machine):

[4] octopus ~ $:~> locate ffi.h /usr/include/x86_64-linux-gnu/ffi.h ....

so in terms of gsll I am fairly sure that everything is in the standard place. By the way keep up the good work as gsll is awesome!

Jason

On Thu, Jun 25, 2009 at 12:52 AM, Liam Healylhealy@common-lisp.net wrote:

On Tue, Jun 23, 2009 at 10:00 PM, Jason Nielsenjdn@math.carleton.ca wrote:

...

On Tue, 23 Jun 2009, Liam Healy wrote:

...

Not so fast...  I'd like to try to come up with a solution that works for the major OSes/distrbutions when things are installed in standard places.  The :cc-flags is a hack to add a new path; why is it necessary?

What version of Linux are you using? What library(ies) are you having problems with? Are they installed in the system-standard places? What files are in the "wrong" place?   Where are they?

As for me, I use Debian.  Everything is installed from the distribution, so packages like libffi-dev place the .h files in the standard places.  For example,

dpkg -L libffi-dev ... /usr/include/x86_64-linux-gnu/ffi.h /usr/include/x86_64-linux-gnu/ffitarget.h ...

I put (include "ffi.h") in libffi-unix.lisp, and that works. My understanding is that almost all distributions conform to the FHS http://www.pathname.com/fhs/ and so this should work on all these distributions.  If that is not the case,  I would like to know why. I do not know how to provide alternative .h paths, but I can ask on the cffi-grovel list if necessary.  I hope it is not necessary; the preferred solution is to (include ...) the files in the right place.

Liam

I am running Ubuntu 8.10 on a dual quad core 64bit system.  Until recently I did not have to do any -I magic to include headers but I do now and you can use the date stamp of my original post as a time-line since before that I had no trouble with compiling vanilla git pulls using sbcl v1.0.27. In truth I use a heavily tuned system as I do rather computationally intensive stuff (this is my test/debug machine):

[4] octopus ~ $:~> locate ffi.h /usr/include/x86_64-linux-gnu/ffi.h ....

so in terms of gsll I am fairly sure that everything is in the standard place.  By the way keep up the good work as gsll is awesome!

Jason

Well then I'm stumped.  Ubuntu should be identical to Debian, and your fii.h is exactly where mine is, and I can't think of a reason it would have changed on you.  It certainly is not anything I did in FSBV or GSLL -- you can check the repository (or better yet, regress to earlier versions and run) and see for yourself.  Those include paths have stayed the same from the beginning (except FSBV for Mac OSX).

I don't think anything changed in CFFI either; I am running a fairly recent version (last week from darcs repo).  But maybe a query to the cffi-devel mailing list (if you're on it) would elicit some helpful insight into what's going on.

I had problems with newer GSLL compilation until I pulled a new CFFI from DARCS (and some of the deendences, I think babel OR alexandria), cleaned out FASLs, and then everything "worked".

(running Debian unstable, bleeding/hemorraging all the way).

best, -tony

blindglobe@gmail.com Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05).

Drink Coffee: Do stupid things faster with more energy!

On Sat, Jun 27, 2009 at 7:23 PM, Liam Healylhealy@common-lisp.net wrote:

On Fri, Jun 26, 2009 at 3:35 AM, A.J. Rossiniblindglobe@gmail.com wrote:

...

I had problems with newer GSLL compilation until I pulled a new CFFI from DARCS (and some of the deendences, I think babel OR alexandria), cleaned out FASLs, and then everything "worked".

(running Debian unstable, bleeding/hemorraging all the way).

best, -tony

Tony,

Excellent point.  It is necessary to pull a new CFFI, at least 0.10.5, which is stated in documentation/index.html (which is also on http://common-lisp.net/project/gsll/).

I routinely wipe out all my fasls when I am testing to make sure everything builds cleanly.  In order to make this easy in common-lisp-controller I wrote a shell script called `clc-make-clean' as follows:

Thanks, much appreciated! I have to add that to the general CL utilities I've got (esp as part of a release testing strategy).

On another subject, I notice you have been doing a lot of work on Lisp interfaces to other science/engineering/math libraries, like R.  My intent in building GSLL was that it would become part of a collection of systems that would have consistent use and interchange of data between different libraries.  So for example, you would be able to make an object representing an array, call a GSLL function, then pass the resulting array to R.  There are a lot of aspects of this problem, but I'm thinking about array standardization as a start.  Do you have any thoughts on this?

The RCLG package has some stuff in the right direction (Rif wrote it, I'm maintaining it). RCL and CLSR, 2 others, have respectively, better lispy interfaces and some better internals (roundtrip and better object mapping). I'd look at Cyrus Harmon's CLSR as a start, as much as I'd love to have you contribute to RCLG.

We ought to be able to seemlessly use R's S4 object systems right out of CL, it's just CLOS reinvented poorly (so have to add some bugs to get the proper mapping, but sigh, you get the point).

So yes, I've got lots of thoughts on this, but I'm not nearly a good enough lisp programmer to make enough progress on what I want to do, and I need to get a few working pieces before heading back to integration.

And BTW, I am working to see about using GSLL as a feasible backend for the lisp-matrix stuff, as you've done a fine job on the overall system development and internals, as well as for some of the other numerical stuff -- however, it would be great to have a robust and consistent front end to many different numerical libraries for testing numerical stability and comparability.

All this just to be able to wrap a sensible statistical DSL directly on top of CL, keeping all of CL around, so that I can once and for all forget about R's annoying syntax burps.

(I do like R, having been responsible for many user-level innovations and demonstrations with it, but it truly sucks as a platform for statistical computing research; it's great for just "computing statistical stuff").

Let me know if there is anything I can do to help out (I don't have much time, but it'll help me in the long run).

best, -tony

blindglobe@gmail.com Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05).

Drink Coffee: Do stupid things faster with more energy!