Problem with compilation of project generator and examples on Ubuntu 14?

Well, I think I found what the problem is - however, if anyone else can confirm, that would be the best.

First, let's note what my glxinfo says by default:

$ glxinfo | grep 'OpenGL \(v\|r\)'
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) IGD x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 10.5.9

So, I apparently have Mesa (driver?) version 10.5.9, which advertises OpenGL 1.4.

On the other hand, I have tried running some of the programs in the debugger gdb, and I get something like this before the crash:

$ gdb --args examples/empty/emptyExample/bin/emptyExample_debug 
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
...
(gdb) b main
Breakpoint 1 at 0x805f327: file /.../openFrameworks/examples/empty/emptyExample/src/main.cpp, line 7.
(gdb) r
Starting program: /.../openFrameworks/examples/empty/emptyExample/bin/emptyExample_debug
...
Breakpoint 1, main ()
    at /.../openFrameworks/examples/empty/emptyExample/src/main.cpp:7
7        ofSetupOpenGL(1024,768, OF_WINDOW);            // <-------- setup the GL context
(gdb) s
...
(gdb) s
ofSetupOpenGL (w=1024, h=768, screenMode=OF_WINDOW)
    at /.../openFrameworks/libs/openFrameworks/app/ofAppRunner.cpp:171
171        settings.glVersionMajor = 2;
(gdb) s
172        settings.glVersionMinor = 1;
...

So, basically, my system advertises OpenGL 1.4 - while openFrameworks sets up everything to use OpenGL 2.1. And, as noted in http://stackoverflow.com/questions/13863996/x-error-of-failed-request-glxbadfbconfig :

You're running fourth-gen Intel silicon so:
glutInitContextVersion(3,2);
is rather...optimistic.
Unless you want software rendering, in which case you'll have to wait a while for Mesa to get up to OpenGL 3.2.

So, my graphics card is:

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller

... and by doing lsmod | grep i9, I can see that the i915 driver is being used; for which I can see:

$ modinfo i915 | grep 'ver\(m\|s\)'
filename:       /lib/modules/3.19.0-26-generic/kernel/drivers/gpu/drm/i915/i915.ko
srcversion:     6C0E6F93C3C45F0A74447EC
vermagic:       3.19.0-26-generic SMP mod_unload modversions 686

Not sure if this srcversion relates to a git commit of sorts or not; but as per https://en.wikipedia.org/wiki/Comparison_of_Intel_graphics_processing_units#Third_generation, the 915 are third generation Intel silicon, for which it is noted under OpenGL API support: "1.4 on Windows, 1.4 on OS X, 2.1 on Linux"; and for Linux, there is a link reference to the page Intel Brings OpenGL 2.0/2.1 To Classic i915 Mesa Driver - Phoronix. Note that in the comments for this post, it is noted:

http://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/intel-linux/35629-intel-brings-opengl-2-0-2-1-to-classic-i915-mesa-driver

Indeed, I see the opengl 2.1 advertised as well as the shading language level 1.2.
But the issue is that this change breaks the Unity desktop to the point of making it unusable. [...]
I believe that the issue is that now unity thinks that it can rely on
some hardware features, that conversely are so painfully slow that make everything hang whenever they are invoked. As a matter of fact, whenever you see unity hanging, if you give enough time to it you will see that it is actually trying to play a fading or a translucency effect.

So, with this in mind, the only question is whether my version of Mesa/i915 driver is capable of advertising OpenGL 2.1. Note that the news post is from April 2013, while I'm running Ubuntu from 2014, which means that it is likely that my driver would have those capabilities (even if it doesn't advertise them). I thought for a while I'd have to recompile from source (from the news post, the git should be at http://cgit.freedesktop.org/mesa/mesa/) - but then I found this:

Bug 64202 – Enabling opengl 2.1 on intel gen3 breaks the Unity desktop (and possibly others)

I did not realize that the opengl conformance level is /already/ configurable via the MESA_GL_VERSION_OVERRIDE environment variable.

Oh... could it be?

$ MESA_GL_VERSION_OVERRIDE=2.1 glxinfo | grep 'OpenGL \(v\|r\)'
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) IGD x86/MMX/SSE2
OpenGL version string: 2.1 Mesa 10.5.9

Well... indeed, it could... So finally, I can test:

$ MESA_GL_VERSION_OVERRIDE=2.1 examples/3d/3DPrimitivesExample/bin/3DPrimitivesExample
[notice ] ofGstVideoGrabber: Probing devices with udev...
[notice ] ofGstVideoGrabber: Found device 0ac8:3420, getting capabilities...
[notice ] ofGstVideoGrabber: detected v4l2 device: Sirius USB2.0 Camera
[notice ] ofGstVideoGrabber: driver: uvcvideo, version: 201480
[notice ] ofGstVideoGrabber: Capabilities: 0x84200001
[notice ] ofGstVideoGrabber: initGrabber(): selected device: Sirius USB2.0 Camera
[notice ] ofGstVideoGrabber: initGrabber(): selected format: 640x480 video/x-raw RGB framerate: 30/1
[notice ] ofGstUtils: setPipelineWithSink(): gstreamer pipeline: v4l2src name=video_source device=/dev/video0 ! video/x-raw,format=RGB,width=640,height=480,framerate=30/1    ! appsink name=ofappsink enable-last-sample=0 caps="video/x-raw, format=RGB, width=640, height=480"
libv4l2: warning v4l2 mmap buffers still mapped on close()

... and indeed - it works:

... and it's not even that bad of a framerate (49-50 fps), for this example at least!

Well, I hope that was it with this problem at least...
Hope this helps someone,
Cheers!