[cells-gtk-devel] "First steps" how to compile problem
Peter Hildebrandt
peter.hildebrandt at gmail.com
Fri Feb 1 11:45:18 UTC 2008
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
More information about the cells-gtk-devel
mailing list