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!