[cl-opengl-devel] Problem compiling cl-opengl for cmucl

[Thibault Langlois]

On Thu, 2006-08-31 at 11:09 -0700, James Bielman wrote:
> Thibault Langlois <tl at di.fc.ul.pt> writes:
> 
> > I'm trying open-gl for the first time and I get the following error:
> >
> > Undefined foreign symbol: "glAttachShader"
> >    [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
> >
> > I am using cmucl 19c on a intel linux. I fetched cffi and cl-opengl from
> > their respective websites today.
> 
> IIRC, CMUCL is unique in that it is rather eager about resolving
> foreign function linkage at compile-time.  In most other Lisps, you
> can define an interface to a C function that doesn't exist, and you
> are alright unless you call it.
> 
> Unfortunately, CL-OPENGL's strategy of defining linkage for every
> OpenGL 2.0 function will break horribly in CMUCL if the GL library
> version is lower, which is probably what's going on in your situation.
> 
> As a workaround for now, you could comment out the DEFCFUNs in
> funcs.lisp that give you errors, or try in SBCL instead of CMUCL,
> which resolves foreign linkage lazily.
> 

Even after commenting the functions that were giving this kind of error,
some examples do not work. 
So I installed sbcl to experiment. cl-opengl compiles fine with sbcl
but, like with cmucl, the only examples that worked are gears and glut-
teapot. The examples from the red book give a division by zero with both
lisps.

CL-GLUT-EXAMPLES> (rb-double)

arithmetic error DIVISION-BY-ZERO signalled
   [Condition of type DIVISION-BY-ZERO]

Restarts:
  0: [ABORT-REQUEST] Abort handling SLIME request.
  1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-
thread" {A6539D1}>)

Backtrace:
  0: ((FLET #:G150))
  1: (SB-VM:SIGFPE-HANDLER #<unavailable argument> #<unavailable
argument> #.(SB-SYS:INT-SAP #X04B0D6D8))
  2: (SB-SYS:INVOKE-INTERRUPTION #<CLOSURE (LAMBDA NIL) {B7C72BD}>)
  3: ("foreign function: call_into_lisp")
  4: ("foreign function: funcall3")
  5: ("foreign function: interrupt_handle_now")
  6: ("foreign function: #x8053C58")

Is it a known issue ?

Another detail: when gears or glut-teapot are running if I destroy the
window (clicking on the cross), the lisp dies too. Is it supposed to to
behave like this ?

Thibault 

> I'm not sure what a long-term solution to this would involve---we'd
> have to resolve functions that may or may not be present at runtime
> (like C programs do with GL_EXTENSIONS).  Blech.
> 
> James