How to Get the Gl Library/Headers

How to get the GL library/headers?

Windows

On Windows you need to include the gl.h header for OpenGL 1.1 support and link against OpenGL32.lib. Both are a part of the Windows SDK. In addition, you might want the following headers which you can get from http://www.opengl.org/registry .

• <GL/glext.h> - OpenGL 1.2 and above compatibility profile and extension interfaces..
• <GL/glcorearb.h> - OpenGL core profile and ARB extension interfaces, as described in appendix G.2 of the OpenGL 4.3 Specification. Does not include interfaces found only in the compatibility profile.
• <GL/glxext.h> - GLX 1.3 and above API and GLX extension interfaces.
• <GL/wglext.h> - WGL extension interfaces.

Linux

On Linux you need to link against libGL.so, which is usually a symlink to libGL.so.1, which is yet a symlink to the actual library/driver which is a part of your graphics driver. For example, on my system the actual driver library is named libGL.so.256.53, which is the version number of the nvidia driver I use. You also need to include the gl.h header, which is usually a part of a Mesa or Xorg package. Again, you might need glext.h and glxext.h from http://www.opengl.org/registry . glxext.h holds GLX extensions, the equivalent to wglext.h on Windows.

If you want to use OpenGL 3.x or OpenGL 4.x functionality without the functionality which were moved into the GL_ARB_compatibility extension, use the new gl3.h header from the registry webpage. It replaces gl.h and also glext.h (as long as you only need core functionality).

Last but not the least, glaux.h is not a header associated with OpenGL. I assume you've read the awful NEHE tutorials and just went along with it. Glaux is a horribly outdated Win32 library (1996) for loading uncompressed bitmaps. Use something better, like libPNG, which also supports alpha channels.

How do header files like OpenGL.h work

Usually, library headers do not contain implementations (exceptions are, for example, header-only libraries, especially with loads of c++ template code). Headers just provide information on how to call library functions, that is, data types and signatures. The implementation is usually contained in a static or shared library.

Strictly speaking, OpenGL is not even a library, but a specification, while OpenGL implementation is usually provided as a shared library. That is, the implementation of OpenGL functions is stored as a bunch of binary data holding compiled code. If you really want the sources, you need to check which implementation of OpenGL are you using (it could be nvidia drivers, for example, and I doubt that the real sources are available).

In order to understand, how this compiled code gets linked with your code and how headers are involved in this process, I recommend you to read more about C++ compillation process and static and dynamic linking.

OpenGL 4 headers

OpenGL core profile headers are located here:

http://www.opengl.org/registry/api/GL/glcorearb.h

This header contains only core profile and ARB extension interfaces, as described in appendix G.2 of the OpenGL 4.3 Specification. It does not include interfaces found only in the compatibility profile.

I think this is what you ask for when you say OpenGL 4.

Here are some OpenGL 4 tutorials:

• http://www.swiftless.com/opengl4tuts.html
• http://antongerdelan.net/opengl/

Where can I get the OpenGL graphics header files?

The OpenGL headers are part of Mesa, and the X11 headers are in Xorg's protocol development package.

How to include header in order?

The clean way to do it is to exercise self-control. Or more to the point, stop including gl.h. If you're using an OpenGL loading library, then it controls your access to OpenGL. Let it do its job and only include its headers.

So there's no need for GLEW_INCLUDED.

As for GLEW_STATIC, that's a define you add to your build system on the command line, not to every file that you use. Much like you don't define NDEBUG or other similar defines.

Compilation fails with #include ... but not with #include ...

After investigating this a bit I found the solution. gcc does not apply the same warning level to system headers as it does for "normal" files (this is mainly because system headers are sometimes doing weird things which are not backed up by the C standard, but are "safe" for the platform they are coming with).

The gcc documentation states (emphasis mine):

-Wsystem-headers:

Print warning messages for constructs found in system header files. Warnings from system headers are normally suppressed, on
the assumption that they usually do not indicate real problems and
would only make the compiler output harder to read. Using this
command-line option tells GCC to emit warnings from system headers as
if they occurred in user code. However, note that using -Wall in
conjunction with this option does not warn about unknown pragmas in
system headers—for that, -Wunknown-pragmas must also be used.

When you include nanovg via <...>, it is treated as a system header.

So doing gcc -Wsystem-headers working.c actually will bring on the warning.

Note that your code is neither working in working.c nor notworking.c, as working.c just hides the warning messages. The proper way to access any GL function beyond what is defined in GL 1.1 is to use the GL extension mechanism, which means you have to query the GL function pointers at run-time. Full GL loader libs like GLEW and glad can do that for you automatically. Many of these loaders (including GLEW and GLAD) work by re-#define-ing every GL function name to an internal function pointer, so when you include the header which comes with the loader, every GL function called in your code (and nanovg's) will be re-routed to the loader-libraries function pointers, and your code can actually work (provided you properly initialize the loader at run-time before any of the GL functions is called).

---

Related Topics