CODEWITHSUNDEEP
openglvisual-studio-2012
DesertEagle_PWN
DesertEagle_PWN

Reputation: 81

Setting up OpenGL: Why am I getting these errors? Why is Visual Studio Freezing?

So I have been programming in console C++ for a while, but I finally decided to try graphical applications using OpenGL. It took me a while to learn that GLUT and other libraries are obsolete, so I began installing and preparing GLEW and FreeGLUT. I managed to get to the point were my includes are working; however, now I'm running into this problem:

  Screenshot

Visual Studio is telling me that I don't have glew32.dll when it is clearly sitting in the system32 folder. Is this not the default folder for these libraries?

In addition, every time I run my program (and hence get this error) the visual studio process continues running in the background, even after the program is closed. It refuses to be ended and it causes another problem: whenever I reenter Visual Studio I get a message saying that the default storage location is currently in use by another instance of visual studio (the one running in the background.) As a result, to continue working I have to restart my computer every time.

Does anyone have any clue what could be wrong with this and how I could get things up and running? This is my first time installing libraries, but I haven't touched random things in the system folder (at least not intentionally) and I've been careful to clean up behind myself when I've done something I shouldn't have.

Other info:

Visual Studio 2012 Latest stable releases of freeGLUT and GLEW Windows 8.1 64bit

Upvotes: 2

Views: 1835

Answers (1)

Andon M. Coleman
Andon M. Coleman

Reputation: 43319

There are a few things worth mentioning here:

  1. You really should not even bother with using the dynamic linking version of glew (glew32.lib). Just link against the static linking library (glew32s.lib) and forget that the DLL version ever existed.

    • The DLL version is more trouble than it is worth, especially since it will not work with other compilers (e.g. g++) on Microsoft Windows.

  2. For goodness' sake, do not install glew32.dll to System32!

    • Never, ever, put any user DLLs there. This is the primary cause of "DLL hell." What you should do is distribute them along with your application instead (e.g. in your .exe's working directory) or if the software has a run-time redistributable installation program (glew does not) ship that with it.

  3. I am willing to bet good money you are running a 64-bit version of Microsoft Windows.

    • You are compiling a 32-bit application, and it will run in Microsoft Windows' 32-bit compatibility layer known as Windows on Windows. All 32-bit DLLs will be sourced from a separate location SysWow64 when running in the compatibility layer.

    • This can be confusing, as you would think that System32 means 32-bit... but for historical reasons System32 actually contains the DLLs for the native version of Windows (32-bit on Win32 and 64-bit on x64).

    • Nevertheless, do not install glew32.dll to SysWoW64 either :)

Since you mentioned in comments that you do not understand what "linking against glew32s.lib" means, I will tell you simply that this line in your header file is causing the linker to use the DLL version of glew:

 #pragma comment (lib, "glew32.lib")

This is an ugly hack for the Microsoft Visual C++ compiler that tells the linker to add this as a dependency. It is not understood by other compilers (e.g. g++), but if your software is always going to be compiled with Visual Studio you can continue to use it.

To change your software to use the static (non-DLL) version of glew, simply replace that line with this:

#pragma comment (lib, "glew32s.lib")

Now you do not need to distribute a DLL along with your program and this whole problem effectively disappears.

Upvotes: 4

Related Questions