unresolved external symbol using GLEW, SDL and OpenGL in VIsual studio 2010 express [duplicate]

Question

I'm using this OpenGL tutorial. I used SDL for the creation of my window and now i need to use glew (see the One more thing section on the bottom of the tutorial). But whatever i link, include, copy or define all i get is unresolved external symbol errors.

I have:

• Linked my project to the GLEW Lib folder
• Added the include folder to my include path
• Copied the include,bin and lib files to the C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\ in the appropiate maps
• copied glew32.dll and glew32mx.dll to my system32 folder
• included and defined different files (see screenshots 2)

I will let the screenshots do the talking, what did i forget?

Screenshots:

were supposed to go here but due to the new user rule i can't include them here. Here is a link

Casaba

You've made all these screenshots, but didn't think about posting linking error. – Togo

@BartekBanachewicz The linker errors are in the screenshots. – Xavierxaviera

Maybe you're using a 32-bit version of one library and a 64-bit version of another. I'm not sure if this would cause a linker error, but I know it can be the source of issues when using multiple libraries. – Xavierxaviera

Also, you could be using x64 DLLs on a x86 application. Try changing it from x86 to x64 in VS. – Xavierxaviera

I try it again using all the x86 libraries. – Casaba

i copied the files in the lib folders of the GLEW binaries and the SDL development libraries. And i still get the same error. I am running a 64 bit windows, but i don't think that matters. – Casaba

progress my friends, i forgot to change the paths to the x86 files in the project properties. I ran it and now only the glew_Experimental error remains. (5 min later) After some research i saw someone stated '#define GLEW_STATIC' must be added to make it work. I already did that but with simple logic, lets remove it and run it, it worked, it doesn't give the unresolved external symbol error anymore and starts the opengl black window as it should, but it does show this in the output window, is that normal? – Casaba

@Casaba Yes, the cannot find or open the PDB file notices are normal. Those windows dlls do not have debugging information associated with them. It is not a problem with your program. – Overblown

In [open.gl/context](the tutorial) (bottom "One more thing") it says "Make sure that you've set up your project correctly by calling the glGenBuffers function, which was loaded by GLEW for you!" with a code sample. i used the code but it doesn't output a 1 in my console, what is going wrong?. i did set my SubSystem in the properties page to Console, otherwise there wouldn't have been a console at all. – Casaba

Answer 1

I think that you need to link to glew32sd.lib or glew32s.lib (depending on debug or release build configuration), since you've defined GLEW_STATIC.

Here's a snippet from a pre-compiled header on a win32 glew application we finished recently. It shows the libraries we linked to:

#pragma comment( lib, "OpenGL32.lib")
#pragma comment( lib, "GLu32.lib")
#pragma comment( lib, "freeglut_static.lib")

#define GLEW_STATIC

#if defined _DEBUG
    #pragma comment(lib, "glew32sd.lib")
#else
    #pragma comment(lib, "glew32s.lib")
#endif

#include <GL\glew.h>
#include <gl\GL.h>
#include <gl\GLU.h>

Note that we used glew32s.lib and glew32sd.lib (the debug equivalent), which I believe is the static lib for glew.

If you have referenced the library and include folders correctly, the only other issue I can think of is that you may need the dll files to be copied into the output folder for your project.

So for example if your project builds to c:\MyProject\Debug\MyProject.exe, copy the dlls to c:\MyProject\Debug.

I hope this helps.

Docilla

Using pragma comment(lib is a very bad habit. This pragma is non-standard, and non-portable plus it forces you to think in the wrong way. Linking with libraries is linker's job, so jamming library references into c++ code is a bad idea in the long term. Do yourself a favor, and link properly by adding libraries into project settings. Or better yet, learn decent build system - cmake/qmake - that can generate project files on demand - because it is quite possible that you ain't going to use visual studio forever. – Hayes

Non standard to what? And portable to where? Is there a standard way to issue commands to two different linkers? And does this perspective have anything to do with the OPs question? If you bothered to look at the OPs method of instructing the linker, you'd notice that it's non-portable too (and specific to the windows platform). So really, thanks for your opinion, but I've used VS for years, and I have no need to switch. Go advertise your tool affections somewhere that its relevant. – Docilla

"Non standard to what?" To C++. Does not exist in C++ standard. "And portable to where?" To ANY non-microsoft compiler, including windows version of gcc. "Is there a standard way to issue commands to two different linkers?" Yes, there is. Use qmake, cmake or scons as a build system. they can issue linker command for different target platofmrs. cmake/qmake can generate vs projects. "and specific to the windows platform" Can't see any platform-specific code. Should be compileable on all platforms with SDL. – Hayes

"And does this perspective have anything to do with the OPs question?" Yes, you recommend questionable/harmful practice, which can create more low quality programmers, and there's already enough of them. – Hayes

#pragmas are compiler directives, they have nothing to do with C++. So how could it be standard to C++? When a compiler doesn't understand a #pragma directive, it ignores them. I have not recommended questionable/harmful practice and you have not offered any evidence to the contrary; only your staunch and poorly elected opinion. Once again, I suggest that the OP has targeted the windows platform and so your rant about your affections for other build tools are completely irrelevant to this discussion. Grow up! – Docilla

"are compiler directives" preprocessor directives. "they have nothing to do with C++" ifdefs and pragmas are documented in C++ standard which defines language, so they have a lot to do with C++. However, pragmas provide implementation-defined behavior. "I have not recommended questionable/harmful practice" Using implementaion-specific extension (pragma comment) will cause a lot of trouble when you'll have to move to another compiler. You will have to migrate code to another compiler eventually. "has targeted the windows platform" no windows tag in first post. – Hayes

"and so your rant about your affections" Linking with static libraries is linker's job. Passing libraries to linker is build system's job. Using non-standard extensions is a bad idea in general. "Grow up!" It seems that, unlike me, you have never encountered consequences of relying on compiler extension before. You need more C++/programming experience. Few more years will do. Have a nice day. – Hayes

Impressive that you can gauge my c++ programming experience without having known about a single project I've been involved with. An invalid inference. Pragmas are non-standard to what exactly? The build tools to which you refer are not part of any standard! Except maybe in your head. "Consequences of relying on compiler extension?" If you're referring to the pragmas, well, that code was lifted for this answer from a project that compiles on win32 and PS3 platforms. The PS3 compiler ignores them. Your argument holds no water. And is irrelevant to the OPs question. – Docilla

let us continue this discussion in chat – Docilla

@Docilla Well if we are just suggesting, then I could say, he is using OpenGL and not D3D so hes not jsut aiming Windows OS. But this doesn't even care. i absoloutly agree to SigTerm, ofc #pragmas are compiler advisings BUT the compilers are respecting the C standards and the standard tells how the compiler has to treat thoose lines inside the code. And additionally, you should know the microsoft compiler has many parts of the standard it's not respecting (some parts even breaking). So #pragma comment is just an additonal dissregard of the standard. – Kistler

And at least the point is calling something not harmfull apears to be relatively... but its a fact its not part of the standard, and the sandard includes all inside the source code (even the comments if they would like to give them a syntax) and if your using compiler specific commands that arent mentioned by the standard it's less compatible and its also erasing of the c standard. so maybe its not harmfull depending of the point of view... but if thats your way of argumenting I could say your answer isnt C++ code ;) – Kistler

@fishfood: what SigTerm stated doesn't warrant a downvote for the answerer (assuming he was the one who downvoted that), but I agree that he has valid points: #pragma once is standard enough throughout compiler implementations (i.e., GCC, VC, and I believe clang) that it is a cleaner (and less error-prone) alternative to #ifndef BLABLAH #define BLAHBLAH <declarations go here> #endif //BLAHBLAH include guards. Despite that, I am of the opinion that portability should only be a compromised when it needs to be. – Byron

Answer 2

This may not solve your immediate problem but may help you dodge other incoming later. I don't know. What I provide is merely a recommendation of another resource for learning how to do what you asked about.

Now, I think your first link is broken, because it links to the screenshots for me. I was about to check out the tutorial but couldn't because of that.

Anyway, I've been using a book called OpenGL SuperBible 5th ed; which is very easily digested.

It sets out expecting you do not know anything about 3D graphics, how to include the libraries, create a window for your system etc. However, it goes into great detail without being overly hard to read for a long while. I finished the book in two weeks (well, during a holiday, doing nothing else).

I'm not affiliated to the book owner in any way, I just liked it a lot and it seems to me that what you're struggling with was graciously handled by it.

Bunny