On Thu, 2006-08-31 at 11:09 -0700, James Bielman wrote:
Thibault Langlois tl@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