Cross-compiling linux-->windows: Getting newer OpenGL support with opengl32.dll

Question

I'm using x86_64-w64-mingw32 toolset, with gcc version 4.8.2 to cross-compile 64-bit windows binaries and libraries from my ubuntu 14.04.1 machine.

I've had no problems cross-compiling and testing my project and various libraries: SDL2 , SDL2_image , SDL2_mixer , SDL2_ttf , libfreetype , libpng , libjpeg , libz , libvorbis , libogg , bullet , flite , polyvox , libnoise .

However, I have issues linking to OpenGL when I'm using features that only exist in newer versions of OpenGL .

First, let me state a few preconceptions, and please correct me if I'm wrong.

• The opengl32.a I'm linking to (in particular, /usr/x86_64-w64-mingw32/lib/libopengl32.a , that I have from ubuntu package mingw-w64-x86-64-dev version 3.1.0-1 ) is from the mesa project.

• This libopengl32.a targets an OpenGL version that seems old. It contains function definition for glBegin

   $ nm /usr/x86_64-w64-mingw32/lib/libopengl32.a | grep ' glBegin$' 0000000000000000 T glBegin 

  But the same with glCreateShader has no matches.

  With the linux library GL.so , both have matches:

   $ readelf -Ws /usr/lib/nvidia-331/libGL.so | grep ' glCreateShader$\\|glBegin$' 2129: 000000000030eaa0 0 FUNC GLOBAL DEFAULT 17 glCreateShader 2312: 00000000002fe940 0 FUNC GLOBAL DEFAULT 17 glBegin 

---

My question is whether or not:

1. I'm just doing things wrong. That for windows, all OpenGL > 1.1 function calls have to be dynamically loaded through extensions, and that I've been spoiled by SDL2/SDL_opengl.h and/or GL/glext . If this is the case, why does GL.so have symbols for all the OpenGL functions, while libopengl32.a does not? And, how do I unify this so that my code becomes unaware of cross-compilation, while using OpenGL 4.0 functions?

2. I have to cross-compile a newer version of libopengl32.a from scratch from the mesa source code. (note: I'm not even sure libopengl32.a comes from the mesa project)

3. ??? (something else entirely)

Answer 1

If this is the case, why does GL.so have symbols for all the OpenGL functions, while libopengl32.a does not?

Because the developers of the particular implementation in question didn't bother to hide, ie not expose the symbols to the outside. The OpenGL operating system ABIs just specify which symbols must be available. They don't specify that additional symbols may not be exposed.

I have to cross-compile a newer version of libopengl32.a from scratch from the mesa source code. (note: I'm not even sure libopengl32.a comes from the mesa project)

DON'T DO THIS! In fact you should never link against a specific version of a OpenGL implementation at all (except if you want to ship that very implementation as a fallback). Always link to some generic interface specification. Never expect anything outside the specified ABIs (not API. ABI = Application Binary Interface) to be exposed. For Windows that's OpenGL-1.1, for Linux at the moment OpenGL-1.2. Anything beyond can be accessed reliable only through the extension mechanism.

??? (something else entirely)

You may want to look at glloadgen ( https://bitbucket.org/alfonse/glloadgen/wiki/Home ), a set of Lua scripts which creates a tightly tailored OpenGL interface loader. With the code generated by glloadgen you don't link against opengl32.lib libopen32.a or libGL.so at all. The library is loaded and all symbols resolved at runtime, largely avoiding all the headaches that you get from a mixed loading environment.