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