[Vm-dev] Cog build and sqUnixOpenGL.h not found

Igor Stasenko siguctua at gmail.com
Fri Apr 8 09:55:18 UTC 2011


On 8 April 2011 11:39, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> On 08.04.2011, at 11:12, Mariano Martinez Peck wrote:
>
> Hi. I was compiling in Linux and I got the erro "The file was not found sqUnixOpenGL.h"
> I easily fixed with
>  sudo apt-get install mesa-common-dev
>
> But then I got:
>
> /usr/bin/ld: cannot find -lGL
>
> and I solve it with this:
>
> delete /usr/lib/libGL.so
> cd /usr/lib/
> sudo ln -s libGL.so.1.2 libGL.so
>
> Finally, and this is my question, I saw a special conf:  CogUnixNoGLConfig  which class comment says: "A slightly modified configuration, which avoids linking with openGL libraries."
> So...my question is...if I would have used that class I would have avoided my problems?
>
> Second, that class CogUnixNoGLConfig that doesn't link to the OpenGL, what it does instead? how this impacts me ?  is there any difference from the performance point of view of the VM or something like that ?
>
> If you do not try to run 3D stuff (that is, Croquet or Balloon3D) it does not affect you at all. For regular rendering on unix, OpenGL is not used.
> The problem is that the display module needs to support some functions for creating an OpenGL window, because they are different for e.g. the X11 display module and the Quartz display module. This is only needed for the B3DAcceleratorPlugin, but some functions are inside the display module. That means the display module needs to be linked with libGL, too. This would make the normal 2D display fail to load on systems without installed OpenGL libraries (e.g. the OLPC XO laptop, or a server that has only X11/vnc and no OpenGL). To support these systems, a configuration without GL is needed.
> A better way might be to dynamically load the needed GL functions. Or put them in yet another module. Then the display module would not have to be linked against libGL. But that work has not been done, yet. We rely on conditional compilation instead.
> Another, possibly simpler, idea would be to compile both versions to different names (e.g. vm-display-X11 and vm-display-X11-NoGL and if loading the first fails, try to load the second one.

Good idea. Could serve as a temporary workaround :)


But in a longer perspective the whole approach is ill-defined.
A B3DAccelerator plugin creates an opengl context under the hood.
But if you look at opengl specs, there are a lot of options and
various tricky ways to initialize the context depending
on what you need (pixel format(s), back buffer etc etc)

Unless you expose all those options through plugin (and B3DAccelerator
in its current shape doesn't covers all of them) ,
the usefulness of it is quite limited.

>
> - Bert -
>
>



-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list