Ok, I hate to admit it at this point.. but Ingo was right on the recommendation to move the OpenGL kit into Mesa. I'm still worried that us forking Mesa 7.8.2 may be a bad idea, however at this point we have few other options. It's going to be quite a bit of work to get Mesa 7.8.2 creating our libGL.so. At the moment I have the following code i'm preparing to submit the following targets to Mesa mainline: libGL.so The code from our OpenGL kit within Mesa haiku-softpipe The swpipe renderer from our code. This is the gallium code i've been working on for a while that includes llvm optimizations, I think moving it into Mesa may solve a lot of the issues i've been having with LLVM symbols. I don't plan on moving the gcc4 swrast renderer into Mesa at this time. haiku-softpipe should offer a substantial performance boost. Long term there isn't any reason the swrast driver can't go into Mesa, but gcc2 takes priority once gcc4 is working. I have a recipe constructed that creates the following: * mesa - OpenGL kit LibGL.so dispatch code * mesa_devel - OpenGL kit headers * mesa_swpipe - OpenGL SoftwarePipe renderer I'm still sorting out some linking issues with mesa_swpipe, but the libGL.so in mesa is functioning. For those who care: https://github.com/kallisti5/mesa -- My mesa work that will be submitted to Mesa upstream. https://bitbucket.org/haikuports/haikuports/src/29c2d2eabc471c1275cec003035cabbd551269d1/sys-libs/mesa/mesa-9.3.recipe?at=package-management -- Mesa 9.3 recipe. 9.3 is the next version of mesa, this is relly just mesa-git -- Alex