I had some chance to play around with this and got a little further, but not much...
I added a hack in my code to do this as per the example file mentioned below... ;;;(use-foreign-library opengl) (eval-when (:compile-toplevel :load-toplevel :execute) (let* ((s (ccl:make-semaphore))) (ccl:process-interrupt ccl::*initial-process* (lambda () (ccl:open-shared-library "OpenGL.framework/OpenGL") (ccl:open-shared-library "GLUT.framework/GLUT") (ccl:signal-semaphore s))) (ccl:wait-on-semaphore s)) With this code, the shared libraries appear to load, but I do get the error message: kevin-mac-pro-3:lisp kevinsmith$ ccl64 ; loading system definition from /Users/kevinsmith/ccl-lisp/babel/babel.asd into #<Package "ASDF0"> ; registering #<SYSTEM BABEL> as BABEL ; loading system definition from /Users/kevinsmith/ccl-lisp/alexandria/alexandria.asd into #<Package "ASDF0"> ; registering #<SYSTEM :ALEXANDRIA> as ALEXANDRIA ; loading system definition from /Users/kevinsmith/ccl-lisp/trivial-features/trivial-features.asd into #<Package "ASDF0"> ; registering #<SYSTEM TRIVIAL-FEATURES> as TRIVIAL-FEATURES Welcome to Clozure Common Lisp Version 1.5-dev-r13523M-trunk (DarwinX8664)! ? (require :cl-opengl) ; Warning: Don't know how to setup a hook before saving cores on this Lisp. ; While executing: #<Anonymous Function #x302000D3A5DF>, in process listener(1). :CL-OPENGL NIL ? I created a stripped down version of my program that just has the cl-opengl and GLUT libraries in it and it looks like the first window comes up, but then it hangs before GL gets a chance to clear the window and do its thing... Is the warning (the hook) the problem ? On Sun, Aug 1, 2010 at 8:02 PM, Gary Byers <g...@clozure.com> wrote: > Apple decided to enforce the restriction that some shared libraries (I > don't > remember which one(s)) only be initialized on the initial thread of the > OS-level > process by executing a breakpoint instruction. (It's the World's Most > Advanced > Operating System!) That breakpoint causes the process to terminate with > the > message you're seeing when the library in question is loaded (directly or > as > the result of loading some library which depends on it) from a CCL listener > thread (or a SLIME REPL thread, or ... any thread other than the initial > one.) > > The general workaround is to replace: > > (open-shared-library "culprit.dylib") > > with > > (run-in-initial-thread-and-wait-until-done > (lambda () (open-shared-library "culprit.dylib"))) > > There are a few issues: > > 1) The affected code may be in a third-party lisp library; it'd be good if > the authors of such libraries made the necessary changes so that people > didn't keep running into this. > > 2) It can be hard to know which libraries are affected. I think that the > actual check-and-breakpoint is in the initialization code for the > CoreFoundation library; whether that's correct or not, it's in some > library that's used by many other things on OSX, so the rule of thumb > is something like "when in doubt, force library loading to happen on > the initial thread in OSX." > > 3) There are several ways to do what I'm calling > RUN-IN-INITIAL-THREAD-AND-WAIT-UNTIL-DONE; I don't think that we yet > offer a standard way of doing this (though CCL::CALL-IN-INITIAL-PROCESS > us present in recent versions of the trunk and is intended to become > an exported/documented/standard interface in the near future.) > > We changed some of our examples when this "check and breakpoint" behavior > was introduced (in 10.6, IIRC); see "ccl:examples;opengl-ffi.lisp", for > instance. > > 4) I'd want to think about this more than I have, but at the moment I can't > think of a reason for OPEN-SHARED-LIBRARY not to at least default to > doing what it does on the initial thread by default. > > > > > On Sun, 1 Aug 2010, Kevin Smith wrote: > > The only hurdle for me for trying out (and maybe switching) to clozure on >> the mac platform is that I can't seem to get the >> cl-opengl package loaded. I get the error: "Trace/BPT trap" when I try >> to load that package. (All other dependent packages >> like cffi, loaded successfully). >> I am using ccl64, version 1.5 on Darwin/MAC OS (DarwinX8664). Latest >> version of cl-opengl. >> >> I believe I also tried it on the 32-bit ccl. Same problem. It looks like >> it only compiles a few source files in the >> cl-opengl package before it dies. >> >> If someone can point out to me how I can trace this to provide more >> information on where it is crashing or maybe someone has >> run across this already with this particular package. >> >> Thanks, >> Kevin >> >> >>
_______________________________________________ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel