thank you I will give this a try in the morning..By the way, I was able to trace my problem with cl-opengl a little further to the cffi function:
(cffi:load-foreign-library '(:framework "OpenGL)) (called from the libraries.lisp file in cl-opengl package) I manually tried this call in the repl outside of the cl-opengl package and it also crashes. checked my *darwin-framework-directories* variable and that seems OK. then I found, you can enter the full path of the framework (library ?) directly, like so: (cffi:load-foreign-library "/System/Library/Frameworks/OpenGL.framework/OpenGL") That also crashes it. Incidentally, the same call worked OK with other non-framework libraries that I tried, like /usr/lib/libm.dylib... but I'll look at your suggestion more closely.. I use this library in sbcl without a problem...(but have other problems with sbcl on the mac). -K On Aug 1, 2010, at 8:02 PM, Gary Byers 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