Unresolved externals compiling with glew32.lib

[omdown]

Platform: VS 2005
OS: Windows 7 64-bit

Trying to compile a very simple test app using GLEW, I'm getting unresolved externals trying. I've simplified it to the following:



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

void render() {
glClear( GL_COLOR_BUFFER_BIT );
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();

glutSwapBuffers();
}

int main ( int argc, char **argv ) {

glutInit( &amp;argc, argv );
glutInitWindowSize( 500, 500 );
glutInitWindowPosition( 100, 100 );
glutCreateWindow( "GLEW Compile Test" );
glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE);

glutDisplayFunc(render);

glewInit();
glutMainLoop();

return 0;
}



Compiling this linking against glut32.lib and glew32.lib gives me:


1>Linking...
1>main.obj : error LNK2019: unresolved external symbol __imp__glewInit referenced in function _main

I ran a dumpbin.exe /EXPORTS of glew32.lib and glewInit is there, so I have no idea why it's having problems. I tell you, I've NEVER had as much problem compiling code as I have since I started working in Visual Studio. I can't track down what could possibly be causing this.
Any ideas?

[Floomi]

I had exactly the same problem as you, and found this thread. I was about to post saying so when, on a hunch, I downloaded the 32-bit version of GLEW instead and copied over the libs/DLLs. (I assume the headers are the same.)

Voila! It now works.

This makes sense, really - link against 32-bit libraries if you're compiling a 32-bit application, even if you're doing so on a 64-bit system.

[omdown]

Hrm. I hadn't considered that... I'll give it a try. I had presumed I was compiling to 64-bit without much thought. My VS2k5 install is in the x86 directory so I suppose it is building to 32-bit...

I've been having a LOT of trouble with other third party libs, so I wonder if that's the issue there too. But I've even gone so far as to rebuild one of them myself (libJPEG, for OpenSceneGraph) and it STILL wouldn't cooperate. Not sure what's up there. I'd presume if I build the lib myself it should be compatible...

[Floomi]

You do have to explicitly set up VS to compile a 64-bit application. More details are on MSDN (http://msdn.microsoft.com/en-us/library/9yb4317s(v=VS.80).aspx), but it seems to boil down to setting /MACHINE:X64 in the Linker -> Advanced options and changing your preprocessor defines from WIN32 to WIN64.

As for building the lib yourself...if you built the Win64 version and tried to link it to a Win32 app, I still wouldn't think it'd work for exactly the same reason.

So I guess you either need to switch your project over to Win64, or then recompile using 32-bit versions of your libs. Presumably the latter, unless you're specifically interested in targeting 64-bit machines only?

[omdown]

If you have to go out of your way to build to 64, I never set it up for it. I'm away from my work machine right now so I can't check for sure but unless it picked up on the fact that I was on 64 and set it up to compile to it for me, I'm pretty sure it should still be set to WIN32. I'm not sure what's going on.

[Floomi]

If you're still set to Win32 then I'd imagine swapping out your libs from 64 to 32 should fix the issue.

[Nach0z]

Since this is in the first three top links on Google, and the answer I found eventually worked isn't here, I figured I'd go ahead and post another answer for posterity:
Go into your Linker settings "project -> {projectName} properties -> linker -> input", in VSC 2010, and edit the 'Additional Dependencies' field to include "glew32.lib" (or glew64.lib, if you're using x64 instead), you'll need to either direct it straight to the glew32.lib or just put glew32.lib in the same folder as your other dependencies. I did the latter.
Worked like a charm after that.