[Gsll-devel] Build error (fsbv)

[A.J. Rossini]

On Thu, Jun 25, 2009 at 12:52 AM, Liam Healy<lhealy at common-lisp.net> wrote:
> On Tue, Jun 23, 2009 at 10:00 PM, Jason Nielsen<jdn at 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 at 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!