unresolved external symbol __imp__glewInit VS __imp__glewInit@0

2
votes

When I use opengl in my program, I come acrross a problem when using "glew": unresolved external symbol _imp_glewInit (when use the glew 1.10.0), as I replace the glew32.lib by version "glew 1.6.0", this problem is solved. However, when I compile the attached simple code in a .cpp file, link step fails with an error: external symbol _imp_glewInit@0. Then I use VS2008's dumpin.exe to inspect glew32.lib in glew 1.6.0 and glew 1.10.0, it turns out glew 1.6.0 has a symbol named _glewInit while glew 1.10.0 has _glewInit@0.

So my question is why these two glew32.libs have different symbol names? If I want to use the new features in glew 1.10.0 and has the error "unresolved external symbol _imp_glewInit", what is the best way to solve it?

 #include "glew.h"
 #include <GL/freeglut.h>
 int main(int argc, char **argv){
    glutInit( &argc, argv );
    glutInitDisplayMode( GLUT_RGB | GLUT_DOUBLE | GLUT_DEPTH );
    glutCreateWindow("123");
    GLenum err = glewInit();
    return 0;
 }

PS: All my test is on Win7, the compiler is VS2008_SP1.

1
c++openglcompiler-errors.lib
It looks like C++ name mangling. What happens if you add extern "C" { before your #include (with the } after it)? – user1118321
@user1118321 thanks, but it does not work, still having the unresolved symbol _imp_glewInit@0 error. – Lipeng Yang

1 Answers

5
votes

@0 is the name decoration scheme for a __stdcall function that is passed 0 bytes worth of arguments (in other words, a void function). Use the proper header that ships with your library so that it uses the calling convention the library was compiled with. In this case, whether you use C or C++ linkage (as suggested in comments) makes no difference because the __stdcall calling convention always adds the underscore at the beginning of the symbol name.

Regarding _imp_glewInit that is another matter entirely, as that is the DLL import stub. In the end, there is almost no real benefit to using the DLL version of GLEW. So I suggest you use the static linking version: glew32s.lib and define GLEW_STATIC to make things easier in the long-run.

To answer your final question: there are no new features in GLEW that you can use just by dropping in a new version of the DLL, your program has to be aware of the extensions GLEW loads when you actually write the code. If there is no code that takes advantage of one of the new extensions, then nothing is gained. This is why the DLL version of GLEW offers nothing special vs. the static library.