C++ – Mesa + Linux : gl. h does not include modern OpenGL

Mesa + Linux : gl. h does not include modern OpenGL… here is a solution to the problem.

Mesa + Linux : gl. h does not include modern OpenGL

This is the environment I’m currently using: Eclipse-Luna, C++11 on Linux Mint -Rebecca.

When I try to use modern OpenGL like VAO or VBO, I get a compiler error that causes the method to fail to resolve.

For example:

GLuint VaoID;                   GLuint is working

glGenVertexArrays(1, &VaoID);


GLuint VboID;              
glGenBuffers(1, &VboID);
glBindBuffer(GL_ARRAY_BUFFER, VboID);
glBufferData(GL_ARRAY_BUFFER, vbo_size, data, usage);

I checked GL/gl.h, GL/glext.h and found that there were only OpenGL 1.x methods inside.

So I checked my OpenGL version glxinfo|grep “OpenGL”. This 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:

Attempting to install or update the package again will only state 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 to fix this without messing with the include directory manually?

If not, how do I get the latest header for my version of OpenGL?


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, this is actually what it should be. If you want to use OpenGL in a platform-independent way, you can only rely on GL 1.1 exported by GL lib, and nothing else should be assumed in the header. GL/glext.h should actually contain more. But by default, it doesn’t provide function declarations for newer functions. recent version of that file, by the way, is always available from the OpenGL website.

For everything after GL 1.1,

you should use GL’s extension mechanism, which basically means that you have to query the function pointer for each GL function >= GL 1.2 at runtime. The glext.h header provides function pointer type declarations, enumeration constants, and other data types. So this is basically like this for every extension (in this case, the new core functionality is considered an “extension”):

#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);
// ...
 function declatations
GLAPI void APIENTRY glBindBufferARB (GLenum target, GLuint buffer);
GLAPI void APIENTRY glDeleteBuffersARB (GLsizei n, const GLuint *buffers); 
// ...
#endif /* GL_ARB_vertex_buffer_object */

Therefore, function declarations are only valid when GL_GLEXT_PROTOTYPES is defined. But you shouldn’t do that. It only works if the GL library happens to export these symbols, which is not needed on most platforms.

In general, people don’t want to manually load hundreds of GL function pointers. There are several OpenGL loading libraries, which handle all of this for you in the background. and GLEW – which for some reason you’ve already installed – is one of them, so you might want to use it. Note that GLEW itself has some issues, especially when used with the modern core configuration file OpenGL context, which is somewhat broken, but it still works.

Related Problems and Solutions