1
\$\begingroup\$

I am trying to figure out how to set up openGL on Linux based operating systems (Ubuntu 12.10) without using any *GLUT libraries. I don't have much experience with developing on Linux distributions.

To be more precise I'm trying to make a statically linked library that compiles on the three major OS flavours (using some preprocessor macros to figure out the os its being compiled on and switch up renderer code, window creation code etc).

On windows I have successfully created a openGL 4.0 rendering context using wglCreateContextAttribsARB and the GL/gl.h provided by mingw.

On Ubuntu I have managed to create a openGL 2.2 rendering context using glXCreateContextAttribsARB and the GL/gl.h provided by mesa3d. This was however in a VMware Ubuntu VM and so mesa(9.0.2 I believe) would only manage to go that far with a virtual graphics card.

So I decided to go ahead and install Ubuntu on a external HDD to take advantage of the graphics card only to later find out that mesa(9.1) can only go up to openGL 3.1. After a little bit of research I figured out that the AMD and Nvidia drivers have support for openGL 4.3. So I installed the AMD 13.1 drivers (I have a Sapphire 7970 vapor-x 6GB) but then the openGL header files that come with it are really strange, GL/glATI.h tries to include windows.h, it doesn't define APIENTRY etc.

The question is whats the proper way of setting up openGL (with 4.3 support) for Linux? And even if the GL/glATI.h files were proper, wouldn't they fail if ran on a Nvidia card?

I'm manually creating the window with XCreateWindow and then I'm loading the extensions with glXGetProcAddressARB so I'm not going to use GLUT or any GLUT-like library.

Improve this question
\$\endgroup\$
2
  • \$\begingroup\$ You can use Khronos' provided headers just fine. So long as you don't call missing functions, it doesn't matter if the library (Mesa) supports them. Same for almost any C/C++ header, due to how prototypes and extern linkage are handled. A single header can have external symbols declared that aren't defined in any library (happens a lot) or can have many symbols declared which are defined in multiple, independent binary libraries (rare, but not unheard of, especially with various UNIX C/POSIX runtime libraries). \$\endgroup\$ – Sean Middleditch Mar 31 '13 at 9:05
  • \$\begingroup\$ Even if you're not going to use a library, I would recommend that you look at the relevant source code in a library like GLFW3 that's licensed under a license that doesn't mind you looking at the source code. They've found and explored every single quirk there is out there, so being inspired by the functions and order they try things would probably be a Very Good Thing. \$\endgroup\$ – Lars Viklund Mar 31 '13 at 9:06
5
\$\begingroup\$

The OpenGL setup is rather straightforward under linux, in comparison to windows. If you link to -lGL you will dynamically link to whatever OpenGL library is installed and should be used, so under a X11-Environment with nvidia driver it will link to the NVidia specific libgl, with a ATI driver to the ATI specific libgl, the OpenGL libs of the different vendors have all a compatible ABI, so nothing is needed to be done from your side there.

For the headers you can use the Mesa headers, or any other generic OpenGL header, as said the ABI of the different libraries is compatible so you can use any headers with them.

You don't need to load the pointers to the functions either, though it could be useful so that your application works on both Windows and Linux the same. Generally you just need to make sure that the header you use defines the needed functions. (They can be linked directly under Linux.) If you want to link the newest version of OpenGL instead of getting the function pointers you'll find the newest headers on the OpenGL website: http://www.opengl.org/registry/

About the context creation I have no clue but I would recommend to use GLFW for it, it is really not necessary to communicate with the native platform directly. That way you can even use the same code for both Windows and Linux.

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ Thank you for the answer, although I still am slightly confused by where I should get the actual GL/gl.h files from. The glxext.h, wglext.h and glext.h files from the opengl website are indeed useful, this way I do not have to write my own typedef GLXContext (*PFNGLXCREATECONTEXTATTRIBSARBPROC) (Display*, GLXFBConfig, GLXContext, Bool, const int*) etc definitions. But using the mesa opengl headers wouldn't mean that I can only go as high as opengl3.1? \$\endgroup\$ – Edward A Mar 30 '13 at 13:52
  • \$\begingroup\$ If you load the functions via glXGetProcAddressARB the header shouldn't matter at all. What kind of context you get depends on what context you request not what header you include. Maybe you could also use the glcorearb.h header instead. (According to the OpenGL Website it is the GL 4 replacment for gl3.h) \$\endgroup\$ – API-Beast Mar 30 '13 at 18:40
1
\$\begingroup\$

It's pretty straightforward on Linux. Just get a buildsystem setup so it can find OpenGL, SDL and GLEW. And use all 3 of those things, SDL for context creation and GLEW for creating the function pointers.

Also, unfortunately for now, I should recommend that you not use mesa. For example, eveerything I'm doing is gl 3.2, and Mesa only has..what? 3.0?

Improve this answer
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.