[cells-gtk-devel] "First steps" how to compile problem - fixed

Sat Feb 2 12:23:17 UTC 2008

Bob Willan wrote:
> Peter and Friedrich,
> 
> Thanks to both of you for your help.  It was the older version of SBCL 
> that was the problem.  I've got a working demo now, too cool.

Glad to hear it worked for you now.  I added a paragraph to the guide 
about installing a recent sbcl.

> Peter, you might mention on your Getting Started page that (require :asdf) 
> might be needed before anything else.  The Debian pkg was setup so I 
> didn't need to do that, but the sbcl 1.0.12 compiled tar I downloaded 
> did - I received a "Don't know how to REQUIRE CELLS." error without it 
> when I typed (require 'cells).  I suppose maybe I should add that to a 
> sbclrc initialization file so its always there?

Yep, exactly.  Thanks for pointing that out.  I added to the guide how 
to include (require 'asdf) (require 'asdf-install) in your .sbclrc.

I also created a section warning potential users that it might be 
difficult ;-)

> Maybe I'll think about moving up to Debian Unstable (except the kernel, 
> because my VMWare Workstation won't work correctly with the latest 
> kernels - my only commercial license and its the only software I have 
> problems with that I can't get around or fix!)

A great testimony to open source :)  Maybe you should check out qemu. 
It is a little harder to set up than VMWare, but does a pretty good job 
these days.  Rumour has it you can even run OSX 10.5 Tiger in there.

Cheers,
Peter

> Thanks, again,
>   Bob
> 
> ===================================
> On Friday 01 February 2008, Peter Hildebrandt wrote:
>> Hi Bob,
>>
>> Bob Willan wrote:
>>> I've been thinking about getting into Lisp and Cells for a while, and 
> your 
>>> how-to prompted me to give it a try now.  Not to mention all the work 
>>> you've been doing, making cells-gtk look like more of a going concern 
>>> now.  Thanks for that.
>> Thanks for the positive feed back.  Though I see that I might have 
>> opened a can of worms here ;)
>>
>>> I followed all your instructions, and when I had a compile problem, I 
>>> removed everything, downloaded again/updated from cvs, and tried again 
>>> from scratch, with the same results.  I'm new at lisp and must say the 
>>> compile errors and debugger aren't exactly intuitive to me, though I'd 
>>> guess it involves the cffi function call :(
>> Ok, I since you included all the relevant logs, I will try to shed some 
>> light on it.
>>
>>> My compile stops in tree-view.lisp, as the lines below show.  I am 
> using 
>>> straight Debian Etch (32bit 2.6.18-5-k7 kernel), gcc that came with it 
>>> v4.1.2 20061115 (prerelease)(Debian 4.1.1-21), SBCL 0.9.16, cffi 
> 0.9.2, 
>>> and the cells/cells-gtk from cvs using the commands on your site.
>> As Friedrich pointed out, try using a newer sbcl.  You can download 
>> binary realeases at sbcl.org.  I have not tested anything with a pre 
>> 1.0.x version of SBCL.
>>
>>> ;; I've listed my links (without the permissions/owner/etc to better
>>> ;; read the lines, but permissions were wide open)
>>>
>>> bob at work1:~/.sbcl/site$ ls -la
>>> total 20
>>> drwxr-xr-x 5 bob bob 4096 2008-01-30 09:32 .
>>> drwxr-xr-x 4 bob bob 4096 2008-01-28 23:53 ..
>>> drwxr-xr-x 6 bob bob 4096 2008-01-30 23:07 cells
>>> drwxr-xr-x 8 bob bob 4096 2008-01-30 23:07 cells-gtk
>>> drwxr-xr-x 8 bob bob 4096 2008-01-30 09:33 cffi_0.9.2
>> ok, that looks nice and clean.
>>
>>> bob at work1:~/.sbcl/site$ ls -la ../systems/
>>> total 8
>>>  cells.asd            -> ../site/cells/cells.asd
>>>  cells-gtk.asd        -> ../site/cells-gtk/cells-gtk/cells-gtk.asd
>>>  cffi.asd             -> ../site/cffi_0.9.2/cffi.asd
>>>  cffi-uffi-compat.asd -> ../site/cffi_0.9.2/cffi-uffi-compat.asd
>>>  gtk-ffi.asd          -> ../site/cells-gtk/gtk-ffi/gtk-ffi.asd
>>>  ph-maths.asd         -> ../site/cells-gtk/ph-maths/ph-maths.asd
>>>  pod-utils.asd        -> ../site/cells-gtk/pod-utils/pod-utils.asd
>>>  
> test-gtk.asd         -> ../site/cells-gtk/cells-gtk/test-gtk/test-gtk.asd
>>>  utils-kt.asd         -> ../site/cells/utils-kt/utils-kt.asd
>> That's perfect, too.  BTW, without the correct permissions, you could 
>> not have gotten that far.  See below.
>>
>>
>> ;;----------------------------------------------------------------------------
>>> ;; I wasn't sure if these warnings when compiling gtk-ffi are
>>> ;; okay/expected or not?
>>>
>>> bob at work1:~/.sbcl/site/cells-gtk/gtk-ffi$ make
>>> gcc -fPIC -c gtk-adds.c `pkg-config --cflags --libs gtk+-2.0`
>>> gtk-adds.c: In function 'gtk_adds_color_new':
>>> gtk-adds.c:77: warning: incompatible implicit declaration of built-in 
>>> function 'malloc'
>>> gcc: -lgtk-x11-2.0: linker input file unused because linking not done
>>> gcc: -lgdk-x11-2.0: linker input file unused because linking not done
>>> gcc: -latk-1.0: linker input file unused because linking not done
>>> gcc: -lgdk_pixbuf-2.0: linker input file unused because linking not 
> done
>>> gcc: -lm: linker input file unused because linking not done
>>> gcc: -lpangocairo-1.0: linker input file unused because linking not 
> done
>>> gcc: -lfontconfig: linker input file unused because linking not done
>>> gcc: -lXext: linker input file unused because linking not done
>>> gcc: -lXrender: linker input file unused because linking not done
>>> gcc: -lXinerama: linker input file unused because linking not done
>>> gcc: -lXi: linker input file unused because linking not done
>>> gcc: -lXrandr: linker input file unused because linking not done
>>> gcc: -lXcursor: linker input file unused because linking not done
>>> gcc: -lXfixes: linker input file unused because linking not done
>>> gcc: -lpango-1.0: linker input file unused because linking not done
>>> gcc: -lcairo: linker input file unused because linking not done
>>> gcc: -lX11: linker input file unused because linking not done
>>> gcc: -lgobject-2.0: linker input file unused because linking not done
>>> gcc: -lgmodule-2.0: linker input file unused because linking not done
>>> gcc: -ldl: linker input file unused because linking not done
>>> gcc: -lglib-2.0: linker input file unused because linking not done
>>> gcc -shared -o libcellsgtk.so gtk-adds.o `pkg-config --cflags --libs 
>>> gtk+-2.0`
>> Yep, perfectly fine.  Same thing for me.
>>
>>> ;;----------------------------------------------------
>>> ;; Compile log starting at tree-view.lisp
>> ... which means you have successfully compiled cells, cffi, and gtk-ffi 
>> (which are the major systems r3equired by the actual cells-gtk system). 
>>   So the issue should be pretty local to that file.
>>
>> If you check cells-gtk/cells-gtk.asd you will notice that tree-view is 
>> one of the last files mentioned, so the major part of cells-gtk got 
>> compiled, too.
>>
>>> ; compiling 
> file "/home/bob/.sbcl/site/cells-gtk/cells-gtk/tree-view.lisp" 
>>> (written 27 JAN 2008 03:01:05 PM):
>>> ; compiling (IN-PACKAGE :CGTK)
>>> ; compiling (DEF-OBJECT LIST-STORE ...)
>>> ; compiling (DEF-OBJECT TREE-STORE ...)
>>> ; compiling (DEFUN FAIL ...)
>>> ; compiling (DEF-WIDGET TREE-VIEW ...)
>>> ; compiling (DEF-CLEAN-UP (SELF TREE-VIEW) ...)
>>> ; compiling (DEF-C-OUTPUT TREE-MODEL ...)
>>> ; compiling (DEF-C-OUTPUT EXPAND-ALL ...)
>>> ; compiling (CFFI:DEFCALLBACK TREE-VIEW-ITEMS-SELECTOR ...)
>>> ; compiling (DEFMETHOD GET-SELECTION ...)
>>> ; compiling (DEF-C-OUTPUT SELECTION-MODE ...)
>>> ; compiling (CFFI:DEFCALLBACK TREE-VIEW-SELECT-HANDLER ...)
>>> ; compiling (DEF-C-OUTPUT ON-SELECT ...)
>>> ; compiling (DEFMODEL LISTBOX ...)
>>> ; compiling (DEFMETHOD ITEMS ...)
>>> ; compiling (DEFMETHOD (SETF ITEMS) ...)
>>> ; compiling (DEFUN MK-LISTBOX ...)
>>> ; compiling (DEF-C-OUTPUT SELECT-IF ...)
>>> ; compiling (DEF-C-OUTPUT ROOTS ...)
>>> ; compiling (DEFMODEL TREEBOX ...)
>>> ; compiling (DEFUN MK-TREEBOX ...)
>>> ; compiling (DEF-C-OUTPUT SELECT-IF ...)
>>> ; compiling (DEF-C-OUTPUT ROOTS ...)
>>> ; compiling (DEFUN GTK-TREE-STORE-SET-KIDS ...)
>>> ; compiling (CFFI:DEFCALLBACK TREE-VIEW-RENDER-CELL-CALLBACK ...)
>>> ; compiling (DEFUN ITEM-FROM-PATH ...)
>>> ; compiling (DECLAIM (OPTIMIZE #))
>>> ; compiling (DEFUN GTK-TREE-VIEW-RENDER-CELL ...)
>>> ; compiling (DEFSTRUCT RENDERER ...)
>>> ; compiling (LET (#) ...)
>> Ok, if you wish to look into this in more detail, open tree-view.lisp 
>> and scroll to line 302.  The offending instruction is:
>>
>>
>> (let ((renderers (make-hash-table)))
>>    (defun register-renderer-data (renderer data)
>>      (setf (gethash (cffi-sys:pointer-address renderer) renderers) 
> data))
>>    (defun recover-renderer-data (renderer)
>>      (gethash (cffi-sys:pointer-address renderer) renderers)))
>>
>> Nothing spectacular here.  The pointer-address function can't be too 
>> complex.
>>
>>> debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" 
>>> {A7BD4C1}>:
>>>   The value NIL is not of type SB-C::PHYSENV.
>> The error is in a SB-xxx package.  THat is often a sign that there is 
>> nothing wrong with your code, but the problem is at a deeper level. 
>> Common solutions are (as Friedrich already pointed out):
>>
>> . update SBCL to something more current.  If in doubt, remove the debian 
>> package first to make sure the current sbcl is called
>>
>> . remove stale fasl files.  These are something like C's object files: 
>> compiled code used instead of the source file.  Just do rm *.fasl 
>> **/*.fasl to remove all compiled files in the current directory and all 
>> subdirs.  Then restart sbcl.  Everything will be compiled freshly from 
>> scratch
>>
>> . you have some leftovers in your current working image.  Restart sbcl 
>> to start clean
>>
>>> 1: (SB-C::LET-CONVERT
>> It works on the let with some internal function
>>
>> ...
>>
>>> 10: (SB-C::COMPILE-TOPLEVEL
>>>      (#<SB-C::CLAMBDA
>>>         :%SOURCE-NAME SB-C::.ANONYMOUS.
>>>         :%DEBUG-NAME (SB-C::TOP-LEVEL-FORM
>>>                       (LET #
>>>                         #
>>>                         #))
>>>         :KIND :TOPLEVEL
>>>         :TYPE #<SB-KERNEL:BUILT-IN-CLASSOID FUNCTION (read-only)>
>>>         :WHERE-FROM :DEFINED
>>>         :VARS NIL {B6E2001}>)
>>>      NIL)
>> This is the part where the compiler (SBcl-Compiler) compiles the let 
> form.
>> So in other words, the SBCL compiler chokes at this rather simple let 
>> clause.  And you say this error persists, even if you recompile 
>> everything from scratch.
>>
>> Therefore my guess really is that the problem is with SBCL.  Try the 
>> newest SBCL.  If the problem persists, we should try to isolate it and 
>> post on the SBCL list.
>>
>> Peter
>>
>>
> 
> 