Mesa + Linux : gl.h does not contain modern OpenGL - c++

Question

This is the environment I currently use: Eclipse-Luna, C++11 on Linux Mint -Rebecca.
When I try to use modern OpenGL like with VAOs or VBOs I get Compiler Errors such that methods could not be resolved.
For Example:
GLuint VaoID; //GLuint is working
glGenVertexArrays(1, &VaoID);
or:
GLuint VboID;
glGenBuffers(1, &VboID);
glBindBuffer(GL_ARRAY_BUFFER, VboID);
glBufferData(GL_ARRAY_BUFFER, vbo_size, data, usage);
I checked the GL/gl.h, GL/glext.h and noticed that I have only got OpenGL 1.x methods in there.
So I checked my OpenGL version glxinfo|grep "OpenGL". Which seems to be fine:
glxinfo|grep "OpenGL"
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.3
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.1.3
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
Trying to install or update the packages again only states that everything is up-to-date.
sudo apt-get install freeglut3 freeglut3-dev libglew1.5 libglew1.5-dev libglu1-mesa libglu1-mesa-dev libgl1-mesa-glx libgl1-mesa-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'libglew1.5-dev' for regex 'libglew1.5'
Note, selecting 'libglew-dev' instead of 'libglew1.5-dev'
Note, selecting 'libglew-dev' instead of 'libglew1.5-dev'
freeglut3 is already the newest version.
freeglut3-dev is already the newest version.
libglew-dev is already the newest version.
libglu1-mesa is already the newest version.
libglu1-mesa-dev is already the newest version.
libgl1-mesa-dev is already the newest version.
libgl1-mesa-glx is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 150 not upgraded.
So is there a way of fixing this without manually messing with the include directory?
And if there isn't how do I get an up to date header fitting my OpenGL version?

Answer 1

I checked the GL/gl.h, GL/glex.h and noticed that I have only got
OpenGL 1.x methods in there.
For GL/gl.h, that is actually how it is supposed to be. If you want to use OpenGL in a platform-independent manner, you can only rely on GL 1.1 being exported by the GL lib, and should also not assume anything more in the headers. GL/glext.h should actually contain something more. But by default, it will not provide function declarations for the newer functions. A recent version of that file can always be obtained from the OpenGL website, btw.
For everything beyond GL 1.1, you should use GL's extension mechanism, which basically means that you have to query the function pointers for each and every GL function >= GL 1.2 at run time. The glext.h header provides the function pointer type declartations, and enum constants, and additional data types. So this basically looks like this for each extension (and new core functionality are considered "extensions" in this context):
#ifndef GL_ARB_vertex_buffer_object
#define GL_ARB_vertex_buffer_object 1
// new types
typedef ptrdiff_t GLsizeiptrARB;
typedef ptrdiff_t GLintptrARB;
// constants for GLenum values
#define GL_BUFFER_SIZE_ARB 0x8764
#define GL_BUFFER_USAGE_ARB 0x8765
#define GL_ARRAY_BUFFER_ARB 0x8892
// ...
// function pointer tpes for every function
typedef void (APIENTRYP PFNGLBINDBUFFERARBPROC) (GLenum target, GLuint buffer);
typedef void (APIENTRYP PFNGLDELETEBUFFERSARBPROC) (GLsizei n, const GLuint *buffers);
// ...
#ifdef GL_GLEXT_PROTOTYPES
// function declatations
GLAPI void APIENTRY glBindBufferARB (GLenum target, GLuint buffer);
GLAPI void APIENTRY glDeleteBuffersARB (GLsizei n, const GLuint *buffers);
// ...
#endif
#endif /* GL_ARB_vertex_buffer_object */
So the function declarations are only effective if GL_GLEXT_PROTOTYPES has been defined. But you shouldn't do that. It will only work if the GL lib happens to export these symbols, and that is not required on most platforms.
Usually, one does not want to load hundreds of GL function pointers manually. There are a couple of OpenGL loading libraries which hanlde all this for you under the hood. And GLEW - which you already installed for some reason - is one of those, so you probably want to use it. Note that GLEW has some issues on its own, notably it is somewhat broken when used in conjunction with modern core profile OpenGL contexts, but it can still be used.

Answer 2

I forgot to mention that I had already included GL/glew.h in my headers. But that didn't fix the compile errors. I checked the file glew.h with eclipse and it shows several error messages. The topmost line marked with an error looks like this:
#error glext.h included before glew.h
Apparently order of includes matters here. After some fiddling the problem boiled down to a very simple change of code. Here is what I had:
#include <GLFW/glfw3.h>
#include <GL/glew.h>
Solution looks like this:
#include <GL/glew.h>
#include <GLFW/glfw3.h>
So I just swapped those two lines and it worked. Thanks for your suggestions again.
Also I removed the GL/gl.h completely.