Hello, 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]
Restarts: 0: [CONTINUE] Return NIL from load of #P"/home/tl/comp/lang/lisp/code/cl-opengl/gl/funcs.x86f". 1: [RETRY] Retry performing #<ASDF:LOAD-OP NIL {58E5F46D}> on #<ASDF:CL-SOURCE-FILE "funcs" {58DF96D5}>. 2: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {58E5F46D}> on #<ASDF:CL-SOURCE-FILE "funcs" {58DF96D5}> as having been successful. 3: [ABORT-REQUEST] Abort handling SLIME request. 4: [DESTROY] Destroy the process
I am using cmucl 19c on a intel linux. I fetched cffi and cl-opengl from their respective websites today.
Any advice ?
Thibault Langlois
--- The full session:
CL-USER> (asdf:operate 'asdf:load-op 'cl-opengl) ; loading system definition from /home/tl/Projects/Systems/cl-opengl.asd ; into #<The ASDF0 package> ; Loading #P"/home/tl/comp/lang/lisp/code/cl-opengl/cl-opengl.asd". ; registering #<SYSTEM :CL-OPENGL {584F4DED}> as CL-OPENGL ; loading system definition from /home/tl/Projects/Systems/cffi.asd into ; #<The ASDF0 package> ; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/cffi.asd". ; registering #<SYSTEM CFFI {5851DA7D}> as CFFI ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/utils.x86f". ; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/features.x86f". ; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/cffi- cmucl.x86f". ; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/package.x86f". ; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/libraries.x86f". ; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/early- types.x86f". ; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/types.x86f". ; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/enum.x86f". ; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/strings.x86f". ; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/functions.x86f". ; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/foreign- vars.x86f". ; Loading #P"/home/tl/comp/lang/lisp/code/cl-opengl/gl/package.x86f". ; Loading #P"/home/tl/comp/lang/lisp/code/cl-opengl/gl/library.x86f". ; Loading #P"/home/tl/comp/lang/lisp/code/cl-opengl/gl/types.x86f". ; Loading #P"/home/tl/comp/lang/lisp/code/cl-opengl/gl/enums.x86f". ; Loading #P"/home/tl/comp/lang/lisp/code/cl-opengl/gl/funcs.x86f".
; Compilation unit aborted.
; Evaluation aborted CL-USER> (lisp-implementation-version) "19c (19C)" CL-USER> (lisp-implementation-type) "CMU Common Lisp" CL-USER>
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.
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
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
On 9/1/06, Thibault Langlois tl@di.fc.ul.pt wrote:
CL-GLUT-EXAMPLES> (rb-double)
arithmetic error DIVISION-BY-ZERO signalled [Condition of type DIVISION-BY-ZERO]
[...]
Is it a known issue ?
Maybe. Try the following perhaps:
(sb-int:with-float-traps-masked (:invalid :divide-by-zero) (rb-double))
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 ?
Not at all. Someone else mentioned this problem in #lisp and was using FreeGLUT 2.2. IIRC, upgrading to version 2.4 fixed that.
On Fri, 2006-09-01 at 00:52 +0100, Luís Oliveira wrote:
On 9/1/06, Thibault Langlois tl@di.fc.ul.pt wrote:
CL-GLUT-EXAMPLES> (rb-double)
arithmetic error DIVISION-BY-ZERO signalled [Condition of type DIVISION-BY-ZERO]
[...]
Is it a known issue ?
Maybe. Try the following perhaps:
(sb-int:with-float-traps-masked (:invalid :divide-by-zero) (rb-double))
It worked fine. Thanks.
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 ?
Not at all. Someone else mentioned this problem in #lisp and was using FreeGLUT 2.2. IIRC, upgrading to version 2.4 fixed that.
I am using freeglut 2.2 too. You must be right.
Obrigado.
Thibault
cl-opengl-devel@common-lisp.net
-
James Bielman -
Luís Oliveira -
Thibault Langlois