Allright, so I've removed my pragma comments and added the libraries to the project properties instead.
What did you do exactly, in what menus?
[/quote]
Specifically, I went into "project name" properties then under Linker > Input (I selected All configurations first) I entered "glew32.lib" and "opengl32.lib" in the Additional Dependencies option. Then I tried to Build Solution in the Build menu.
Linker errors in Visual C++ 2010
Author
Well, if you're using glew32.lib, make sure that the glew32.dll is located somewhere your project can find it (in the project directory is the easiest place). Also make sure that the program can find glew32.lib as well (you may have to add its folder under Additional Library Directories in Linker/General).
I'm not sure about 2010, but in 2008 if you want to statically link to GLEW you need to link to glew32s.lib and #define GLEW_STATIC before including glew.h, so maybe try that.
Specifically, I went into "project name" properties then under Linker > Input (I selected All configurations first) I entered "glew32.lib" and "opengl32.lib" in the Additional Dependencies option. Then I tried to Build Solution in the Build menu.
Try giving full path to library, it may still be finding old versions.
Author
Well, if you're using glew32.lib, make sure that the glew32.dll is located somewhere your project can find it (in the project directory is the easiest place). Also make sure that the program can find glew32.lib as well (you may have to add its folder under Additional Library Directories in Linker/General).
I've done that. I've also tried putting it in System32 and SysWOW64. Will not help.
How difficult would it be to check for extensions on your own? Because, that's what GLEW's used for, isn't it?
Shouldn't I just be able to use glGetString and see if the extensions are available and then use them? Or does GLEW do other things as well?
"GLEW provides efficient run-time mechanisms for determining which OpenGL extensions are supported on the target platform." From the site.
I'm not sure about 2010, but in 2008 if you want to statically link to GLEW you need to link to glew32s.lib and #define GLEW_STATIC before including glew.h, so maybe try that.
This did not work. Could not find any glew32s.lib and defining GLEW_STATIC before including glew.h did nothing. Thanks for trying to help, though!
Thanks again guys. Any more tips?
Author
[quote name='tre' timestamp='1304874485' post='4808150']
Specifically, I went into "project name" properties then under Linker > Input (I selected All configurations first) I entered "glew32.lib" and "opengl32.lib" in the Additional Dependencies option. Then I tried to Build Solution in the Build menu.
Try giving full path to library, it may still be finding old versions.
[/quote]
Allright. This made the errors go away and my project compiles. Although... this won't work:
if(wglewIsSupported("WGL_ARB_create_context") == 1){
alert(L"Using 3.x context!");
hrc = wglCreateContextAttribsARB(hdc, NULL, attributes);
wglMakeCurrent(NULL, NULL);
wglDeleteContext(tmpOGLContext);
wglMakeCurrent(hdc, hrc);
}else{
alert(L"Using 2.1 context.");
hrc = tmpOGLContext;
}So now I'm thinking that maybe it hid the errors but that it's still there. Everytime this code is run, it gives me the 2.1-message. And according to the OpenGL Extensions Viewer 3.0, I have the "WGL_ARB_create_context" available. As well as its function "wglCreateContextAttribsARB"...
Thanks for this!
Author
Sorry for making ANOTHER post... that's three in a row.
[s]A few things. I have now noticed that I had written "glewInit()" wrong... so, that's fixed.
I also added a few alerts in there:[/s]
[s]This gives me "GLEW is not OK!". But... when I get to the part that checks for "WGL_ARB_create_context" I get my message "Using 3.x context!".
Now I'm really confused... why is GLEW not OK and still functions? Does it function? How can I find out? edit quickly... I mean I can check it out by using non 3.2+ context stuff but that takes quite some programming [/s]
Never mind. Nothing to see here I'm being a dork. if(GLEW_OK != err) means that there's a problem with GLEW. Obviously it's not OK then. I put my alerts in the wrong order. *facepalm*
I was under the impression that I allways had to put the dll's in system32 and/or SysWOW64. Is this incorrect?
[s]A few things. I have now noticed that I had written "glewInit()" wrong... so, that's fixed.
I also added a few alerts in there:[/s]
GLenum err = glewInit();
if(GLEW_OK != err){
alert(L"GLEW is OK");
}else{
alert(L"GLEW is not OK!");
}[s]This gives me "GLEW is not OK!". But... when I get to the part that checks for "WGL_ARB_create_context" I get my message "Using 3.x context!".
Now I'm really confused... why is GLEW not OK and still functions? Does it function? How can I find out? edit quickly... I mean I can check it out by using non 3.2+ context stuff but that takes quite some programming [/s]
Never mind. Nothing to see here
I'm being a dork. if(GLEW_OK != err) means that there's a problem with GLEW. Obviously it's not OK then. I put my alerts in the wrong order. *facepalm*
Well, if you're using glew32.lib, make sure that the glew32.dll is located somewhere your project can find it (in the project directory is the easiest place). Also make sure that the program can find glew32.lib as well (you may have to add its folder under Additional Library Directories in Linker/General).
I was under the impression that I allways had to put the dll's in system32 and/or SysWOW64. Is this incorrect?
Note that the compiled executables will be in [project name]\release and [project name]\debug, but the working directory by default (where the dlls should be) is [project name]\[project name]
You can normally put the dlls in system32, however the executable will probably use the dlls in your project folder first if present; make sure both the lib and dll are the same version
You can normally put the dlls in system32, however the executable will probably use the dlls in your project folder first if present; make sure both the lib and dll are the same version
Note that the compiled executables will be in [project name]\release and [project name]\debug, but the working directory by default (where the dlls should be) is [project name]\[project name]
You can normally put the dlls in system32, however the executable will probably use the dlls in your project folder first if present; make sure both the lib and dll are the same version
To find out which dlls are actually used, I highly recommend sysinternals. They are free tools from Microsoft, which you can find here: http://technet.microsoft.com/en-us/sysinternals/bb795533
process explorer - great replacement for 'task manager', it tells you which dll's are loaded, which files are opened, etc. per process
process monitor - great tool which tells you the files/registry your process uses. Process explorer gives you a snapshot (does not show you which files were opened, only currently opened files), process monitor shows you entire history of the process.
There are plenty of other important tools there as well.
You can put the .dll's in system32 as well, but for me, rather than mess with polluting my visual studio install directory with libs and my system32 with dll's that I use for development, I just put all my sdk's and libs in one place, and always include them explicitly through "additional include directories", and then always put my .dll's in the project folder.
This saves a lot of confusion as to what is included versus what isn't, especially when changing versions of things. Then I know exactly what I'm including all the time, and I don't have to look around deep in system files to try to find if I have old libs there or not.
This saves a lot of confusion as to what is included versus what isn't, especially when changing versions of things. Then I know exactly what I'm including all the time, and I don't have to look around deep in system files to try to find if I have old libs there or not.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
