Hi Cyrus,  Thank you for your reply.  I did manage to get cl-opengl running satisfactorily with my own program and the glut examples with a single thread build sbcl on darwin64.  I did have numerous package build issues where things didn't quite work right out of the box, but I was either able to get around them or it turned out that the cl-opengl didn't actually need the problematic packages.

The problems started when I started using a threaded build with sb-thread feature turned in the custom build .lisp script when sbcl was compiled).  So, why do I need threads ?  I'm building an interactive graphics environment in cl-opengl to for computer vision research.  The real beauty of a lisp environment is to be able to be able to issue lisp commands or function calls in the repl to change the state of your running program while it's mainl-oop continues to run and accept user and window events.  The only OTHER way I can think of doing this is to write the environment in C/C++ and call an embedded lisp interpreter from the main loop.  this is a really different kind of design - once in which the implementation is really done in C++ with a foreign embedded language (like the way AutoCAD or EMAC implements it).  If I went this route, I'm not sure I would choose an embeddable lisp though, it would probably be either scheme or lua - but that's a different topic.

If I had additional time (iin addition to the deadline I set for myself to write the actual system), I would be happy to chip in and help try to fix all of this or at least be a good tester for the folks working on it, but if I do that I will be spending all my time hacking sbcl and I won't get anything done :-)   (or maybe switch back to a linux system)..- but I do understand and appreciate the complexity of getting all of this to work on multiple platforms with the open source volunteers working on this. It's pretty impressive to see what has been done already - I'm definitely not complaining here..

On Sat, Jul 3, 2010 at 12:41 AM, Cyrus Harmon <ch-sbcl@bobobeach.com> wrote:

Hi Kevin,

I think there are a couple of issues here. First, threads have been around for a while on x86/darwin and, more recently, x86-64/darwin. There are still some nagging unresolved issues that show up under the various threads tests. The upshot seems to be that threads work reasonably well on darwin, but aren't as reliable as they are on linux, for which threads were originally built (using futexes, unavailable on darwin).

As for the problems with cl-opengl, I think this is another issue. I made some efforts to try to get this to work not too long ago, but didn't come away happy. The first problem was that loading shared libraries was rather problematic due to the so-called darwin-dlshim. This has been resolved by removing the shim and using dlopen/dlsym.

The second problem is that loading shared libraries seemed to cause a Trace/BPT exception when the dlopen call was coming from a thread other than the initial thread. I think I managed to get around this by linking the SBCL executable against -framework CoreFoundation.

After those fixes, I was able top asdf:oos 'asdf:load-op cl-opengl, cl-glu and cl-glut, but I'm still unable to get a proper window up and running, I'd try using the 1.0.40 sources and build your own version with threads that is linked against -framework CoreFoundation.

good luck,


On Jul 2, 2010, at 2:56 PM, Kevin Smith wrote:

> Are sb-threads on darwin intel platform still "experimental"  I have 1.0.39 and I and experiencing weird hangup problems when running under slime. doesn't happen when built without threads and doesn't do it when running the program directly from the repl.  I did try to build version 1.0.40, but unsuccessfully because the sb-posix contribution (whatever that is) didn't build and I needed to compile my packages.
> I'd be interested in where I can find any tips on building a workable sbcl platform on the mac (intel) with cl-opengl and a gui library (cl-gtk2 was suggested by another subscriber because it supports some things I'd like to do with a threaded system). I have bits and pieces working - but - man this is an uphill battle for me  btw, I've tried other lisp systems (like closure cl) and actually ran into -MORE- problems (but a different set of them).  maybe it's just me :-)
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________
> Sbcl-help mailing list
> Sbcl-help@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sbcl-help