Linker problems to GLEW (can't be my graphic card, can it)

First of all, hi! I’m a 2nd year in IT that’s into game design, and recently came across a stump, because software rendering is taking too big a chunk of out my CPU to be viable, and so I’m trying to set up OpenGL, to learn a little of it, and have my graphics be drawn by the graphics card, freeing my CPU for the rest of the logistics!

I’m programming c++, in Code::Blocks IDE, using SDL for the context framework, and as seen everywhere, trying to set up glew to ease OpenGL’s use.

And I’m having some issues with the linker setup, namely:

obj\Release\main.o:main.cpp:(.text+0x49): undefined reference to `_imp__glewExperimental'

obj\Release\main.o:main.cpp:(.text+0x66): undefined reference to `_imp____glewGenBuffers'

I think I did it all right:

-glew32.dll to sys64 (the folder where windows gets the .dll)

-search libs to glew lib folder

-search includes to glew include folder

-add glew32.lib to linker

It’s detecting the lib well I believe, because without it I can’t compile glewInit(); right.

My includes are:

#include <GL/glew.h>
#include <SDL/SDL.h>

I’m starting to suspect (based on a friend’s advice) that it may be my graphic card… but it’s “recent”, HD 5470 mobility.
I’ve been, exaggerations aside, an entire afternoon and evening yesterday trying to get this to work!

Thank you!

If it’s a link error, it almost certainly doesn’t have anything to do with your graphics card.

Just websearch on your error message. These are two of the first posts that come up:

Yeah, I’ve been to those and dozens others countless times already. I’ve posted twice to stackOverflow, and no one’s being able to tell what’s wrong, what the friend told me is that my graphic card could be old, and therefore doesn’t support those instructions, or something like it. (I have no idea, I’m not experienced in this area… am completely new)

I kinda hate advertising my own stuff, but have you considered not using GLEW? The static vs. DLL issue is almost certainly what’s catching you here. GLEW can be built as a static library or as a shared library. You can link to the .lib for the static or shared library. And you can compile your code against the static or shared library.

The problem is that everyone must agree. If you want to use GLEW as a static library correctly, you must build it as a static library, link to the static library in your project, and build your project using the appropriate #define that tells it to use a static library. The same goes for dynamic. If you don’t do this correctly, you’ll get a linker error.

There are other OpenGL loaders you can use, and many of them don’t have this static vs. dynamic issue. GL3W provides core OpenGL (and only core OpenGL) as a static library. glLoadGen always links statically; it’s not even a library in the strictest since of that term. You generate .h and .cpp files, and you simply include them into your project as though they were your own files. The OpenGL SDK’s GL Load system provides all extensions and specialized headers, but it’s slightly more complex to link to than simply including .h and .cpp files in your project.

In short, if you’re having trouble with GLEW, while it’s good to learn how to work through those problems, there are alternatives you should consider.

Yeah, such are the joys of Windoze’s __declspec(dllexport) / __declspec(dllimport) annoyance. Tremendous source of code clutter.

In Linux, by default it just works – no silly “am I going to link with a shared (dll) or static library” nonsense at compile time. You shouldn’t have to know, and you don’t!

Though if you want to be paranoid and hide a bunch of globals that probably shouldn’t have been global in the first place (hint!), then there is attribute ((visibility))

(And just to clarify “everyone” in your post, by this I assume you mean all the constituent code in your application – not all code on the machine, which is what I first thought.)

Wow thanks for the replies! Yeah, I considered using others: I tried gl3w, but it won’t work: the .py script keeps blabbing about Error Syntax and won’t lead to anything… and couldn’t find any solution for that.
As for glLoadGen, I’ll try it now, thanks!

EDIT: I had no idea I needed a backwards python! Gl3w needs to have 2.7 or before that, others won’t suffice! Hope I get this one working proper.

And more issues…

Function that’s built by Gl3w script which has the errors:

static void *get_proc(const char *proc) - line 19
void *res;

res = wglGetProcAddress(proc); - line 23, first error
if (!res)
res = GetProcAddress(libgl, proc); - line 25, second error
return res;

Build errors:

||=== LearnOPG, Debug ===| C:\CodeBlocks\LearnOPG\gl3w.c||In function ‘void* get_proc(const char*)’:expressionless:

C:\CodeBlocks\LearnOPG\gl3w.c|23|error: invalid conversion from ‘PROC {aka int (attribute((stdcall)) )()}’ to ‘void’ [-fpermissive]|

C:\CodeBlocks\LearnOPG\gl3w.c|25|error: invalid conversion from ‘FARPROC {aka int (attribute((stdcall)) )()}’ to ‘void’ [-fpermissive]|

||=== Build finished: 2 errors, 0 warnings (0 minutes, 0 seconds) ===|

Can you give me detailed instructions on what to do if possible, in order to set up gl3w?

I’m getting undefined references to wglGetProdAddres@4. Googling it up, but detailed instructions on what I should do regarding the entire gl3w setup would be great if possible, the site is so short on help.


I managed to get it working! Small “guide” on the steps to go about setting gl3w:

First of all, download gl3w at

Then, download Python 2.7.3:

(can’t be the latest version, because the script’s not made for it)

Next, run the script. It’ll generate glew.c in the source folder, and glew.h and glcorearb.h in the include/GL/ folder.

Take the three of them, and either add them directly to your project, or (easier to do the includes), move them into your project’s source files folder, and add the 3 into the project.

In your main source AND in your “glew.c” source, you want to change the include to #include “gl3w.h” Consequently, you’ll have to change gl3w.h’s include to #include “glcorearb.h”

This is because you changed their folder setups, the compiler will throw “can’t find xxx” otherwise.

And don’t forget to link to “opengl32”, simply add the library as such. In Code::Blocks, you select the root project, go into “build options”, select the root project once again (above Debug and Release), go to Linker Settings, Add, and type just “opengl2” without the quotes.

That’s all!