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