As discussed in my last post I am working my way through some OpenGL 3+ tutorials. In the process I have had to use GLEW. GLEW is a wrapper for OpenGL functions in the newer versions of OpenGL. It means you don’t need to call glGetProcAddress a ton of times before you can actually draw anything. It is very handy but I find it does not play nice when you are trying to link to it. To begin with the dll does not strip anything from the symbol name. What that means is glewInit is called _glewInit@0 in the dll. This isn’t much of an issue in fact its quite nice to know that the @0 means that I don’t need to pass any params. Its only mildly annoying when you have got used to dlls not having it. The bigger issue is finding the function pointers.

glBindVertexArray is a function found in OpenGL 3+ it therefore has to be loaded through GLEW. The dll informs me that it is called __glewBindVertexArray. I can understand the change between gl and glew as its to prevent any collisions. The extra underscore threw me to begin with but then it is probably because this is a pointer to my function and it is an extra warning to treat it special. My main problem with it is if I am using the .lib file to link with then I can’t find the sysmbol __glewBindVertexArray. Instead the symbol happens to be __imp____glewBindVertexArray. I assume the __imp__ part is something to do with this being a variable that is filled out when GLEW inits but I will investigate this further. All in all it means I will have to create a macro if I want to be able to link my code with ALINK and MS LINK. 

Whilst looking into this issue I also played about with changing to using static lib files. They would resolve my issues but at the same time I would never be able to link with ALINK since the static libs use parts of ALINK that were never finished. A big fancy macro looks like the best solution.