what are opengl's standard header files and what do they do?

They define an existing implementation of the OpenGL rendering specification, such that you can use it, as long as you are linking with it when building.

With some exceptions, such as in Linux you can build OpenGL applications as long as you have the libmesagl1-dev (or something, i forget) package. However, without graphics drivers, you will likely not be able to create hardware OpenGL contexts, which is what you would want when testing your games. There are of course benefits to using software implementations, because they tend to have much wider limits (eg. rendering to extremely big images).

Regardless, the typical usage of headers are:

1. #include some headers

2. Include some objects, or a collection of objects (archives/libraries) to the linking process

3. Success

The compilation process can fail if you:

1. Didn't include the headers in the right order, as some horribly built headers work that way. Sometimes we just have to accept that.

2. Didn't use the correct header version, or platform-specific header. Most headers are built multiplatform, because that is ALWAYS possible. Sometimes they aren't, and well, see above.

3. Didn't specify the correct paths to these headers. This is typically very easy to do, since many of them are already included to begin with.

4. Try to use libraries and headers that came with another project pre-built. They can be old, and have quirks that might not work on your modern compiler suite.

The last one (4), is what is plaguing you. Just so you know.

The linker process can fail if you:

1. Didn't add all the correct libraries required to compile with a library. For example on Windows you typically need -lgdi32 -lopengl32, sometimes only the latter, while on Linux you will need a much larger commandline due to Xorg-dev being split up in many parts. On linux this is solved with pkg-config <package-name> --option.

2. Didn't specify whether or not you would like to link statically (.a / .lib) or dynamically (.so / .dll), usually through a -Ddefine compiler/linker option.

The difference is largely superficial, although if the .dll you are using is native to your system, it can be significantly faster than static linking. Static linking provides you with the ability to reduce dependencies and can let you share your program with others who may not have installed these dependencies.

On the other hand, the dynamic library could be generic, and thus you could ship it, where your static build could be faster on your system, but that assumes everyone that uses your program must also build it prior. It's not a good way to give your friend your game though. They just want the .exe file to click on.

3. Didn't provide visibility to the libraries you are linking with, through the -L option with gcc. Libraries are typically installed in an already-visible place on Linux, however on windows you always need to add the libraries you need yourself, with -L, unless they came with your compiler. Freeglut does not come with any mingw package, for example.

4. Using prebuilt libraries that came with some project you downloaded somewhere, which happen to be incompatible with your compiler suite, or your system (somehow). It's sort of unlikely on windows, but I guess it can happen. I'm not entirely sure how it all works. Considering how "static" windows is, I would assume it should just work.

Again, I'm leaning towards (4).

So, how do you even work with OpenGL on any system? You either learn absolutely all the quirks by doing, or you use something else - aka. standing on the shoulders of giants. I did everything myself, and I consider it now a waste of time. My build systems work perfectly across all 3 platforms I happen to have access to, but it is brittle in that it only works on MY linux variant (ubuntu), as well as Windows and OS X.

If I had been using a game engine, or even better, a bigger media library to begin with - I could have been doing alot of other things for quite some time.

Regardless, the typical usage of headers are:

1. #include some headers

2. Include some objects, or a collection of objects (archives/libraries) to the linking process

3. Success

Is this true? Because standard header file in c, c++, or java give prototypes and define constants for functions that are going to be used and have nothing to do with the linking process.

What are the opengl standard libraries and what are they used for?

I am just learning opengl but I thought freeglut was also a library? What is glew, gl, glu I thought these were all libraries as well? And I don't know what these are for.

I am just learning opengl but I thought freeglut was also a library? What is glew, gl, glu I thought these were all libraries as well? And I don't know what these are for.

GLUT is a library which mostly handles window/context creation and user input. Some alternatives are GLFW and SDL.

GLEW is one of many libraries which loads OpenGL function pointers, saving you from having to do it yourself manually.

GLU is a high level utility library which is deprecated. A lot of its matrix creation functions can be replaced with equivalent functions from GLM, which is a math library which tries to mimic the GLSL vec/matrix types.

All of it, including the reference implementation, are just file names that are used by convention and not by standard.

Part of it can be explained by a history lesson. Before 1992 there were many different 3D libraries out there. Silicon Graphics (SGI) had one of the most popular set of libraries, called IrisGL. In a move to try to standardize code across the industry they removed all the platform-specific bits that they could find and published the function calls and desired functionality as OpenGL.

Note that they provided no source code, no reference implementation, no file naming conventions. They specified function names, parameters, and behaviors. Different implementations could use any file names and libraries they wanted, and many did. Since the old IrisGL implementations were essentially a reference implementation, if you were working on an O2 or Indy or other SGI hardware you would still reference their IrisGL libraries.

The OpenGL specification has evolved many times over the years, but it still specifies only function names and behaviors.

Today the reference implementation uses glcorearb.h but in the past it many names have been used that depend entirely on the implementation, such as gl.h opengl.h, and other names. There is no magical name to invoke.

All the other libraries like glu, glew, glut, DevIL, and others are just things people wrote for convenience. They aren't all that much different than downloading any number of matrix math libraries, or window management libraries, or even libraries like SDL. Again, no standard for any of it, those libraries are just useful code people share.

Is this true? Because standard header file in c, c++, or java give prototypes and define constants for functions that are going to be used and have nothing to do with the linking process.

Kaptein is describing the entire compile/link process. The OpenGL headers are C headers. You are correct that they declare prototypes and constants (you're wrong about Java, though, as there are no headers or prototypes there, but I won't expound on that) and are not directly involved in the link step. But, when you call a prototyped function, the linker expects the implementation of that function to be in an object file or library somewhere. If it can't find the implementation, you will get linker errors. So the header files do have an impact on the link step in that regard.

@4mad3u5: From what I've gathered from here and from your other threads, your understanding of the C/C++ compilation process is flawed. @Aldacron summarized the linking part really well; for a detailed explanation, read chapters 1, 2, 3, 4, 9, and 11 of An Introduction to GCC.