On Thu, 2006-08-31 at 11:09 -0700, James Bielman wrote:
> Thibault Langlois <[EMAIL PROTECTED]> 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
_______________________________________________
cl-opengl-devel mailing list
cl-opengl-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
