I'm trying to set up my GLEW and freeGlut libraries on Windows 7 (64 bit) working with Microsoft Visual C++ 2010 IDE (which is from what I can tell a 32 bit program.)
I've been looking around and I'm getting a few different answers as to where the .lib, .dll and header files go.
Options for .lib files:
C:\...\Program Files(x86)\Microsoft Visual Studio 10.0\VC\lib\
C:\...\Program Files(x86)\Microsoft SDKs\Windows\v7.0A\Lib\
Options for .dll files:
C:\Windows\System32\
C:\Winddows\SysWOW64\
or within the Debug folder of the project
Options for header files:
C:\...\Program Files(x86)\Microsoft SDKs\Windows\v7.0A\Include\gl
C:\...\Program Files(x86)\Microsoft Visual Studio 10.0\VC\include\ (then make a GL folder to put the header files in)\
Most importantly, which way will work? And, are there options that I am not considering?
0
Where is the best place to put your .lib, .dll and gl header files?
Started by DontReferenceMyPointer, Apr 19 2012 05:04 PM
10 replies to this topic
Sponsor:
#2 Members - Reputation: 1874
Posted 19 April 2012 - 05:21 PM
And, are there options that I am not considering?
Yes. You can set up your own directories. For instance, I place all of my third party libraries under "C:\bin\sdk\". I then set up property sheets for each library that I can add into my project that will change my project's properties to include the specific libraries' appropriate directories. This is especially useful if libraries are named the same for different builds -- i.e., my project links to "SDL.lib", but a property sheet named "SDL-1.2_debug.vsprops" selects the 1.2 debug version of the SDL library.
Also, please do not pollute your Windows directories with dlls. It will make updating third party libraries a nightmare for projects built with older versions and may cause you to miss a library or two when shipping out your project (assuming a simple zip-and-deploy plan). I would instead recommend copying (or even symbolic-linking) the libraries' DLLs to your executables' (debug and release, x86/amd64) working directory.
#3 Members - Reputation: 3828
Posted 19 April 2012 - 05:32 PM
For headers and libs I generally set up a directory under Program Files for each framework, and try to match the standard include paths otherwise. So, for example, with GLEW I'd have C:\Program Files (x86)\GLEW with the .h files going into include\GL and the .lib files into lib under that. Then I set up my environment to add "C:\Program Files (x86)\GLEW\include" to include directories and "C:\Program Files (x86)\GLEW\lib" to library directories. That way I can #include <GL/glew.h> in my program and it's consistent with <GL/gl.h>. Maybe there's some OCD in that, but it does keep the headers having consistent, predictable and expected locations.
Sage advice on .dlls above; heed it.
Sage advice on .dlls above; heed it.
It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.
#4 Members - Reputation: 126
Posted 20 April 2012 - 04:22 PM
Yes. You can set up your own directories. For instance, I place all of my third party libraries under "C:\bin\sdk\". I then set up property sheets for each library that I can add into my project that will change my project's properties to include the specific libraries' appropriate directories. This is especially useful if libraries are named the same for different builds -- i.e., my project links to "SDL.lib", but a property sheet named "SDL-1.2_debug.vsprops" selects the 1.2 debug version of the SDL library.
Also, please do not pollute your Windows directories with dlls. It will make updating third party libraries a nightmare for projects built with older versions and may cause you to miss a library or two when shipping out your project (assuming a simple zip-and-deploy plan). I would instead recommend copying (or even symbolic-linking) the libraries' DLLs to your executables' (debug and release, x86/amd64) working directory.
For headers and libs I generally set up a directory under Program Files for each framework, and try to match the standard include paths otherwise. So, for example, with GLEW I'd have C:\Program Files (x86)\GLEW with the .h files going into include\GL and the .lib files into lib under that. Then I set up my environment to add "C:\Program Files (x86)\GLEW\include" to include directories and "C:\Program Files (x86)\GLEW\lib" to library directories. That way I can #include in my program and it's consistent with . Maybe there's some OCD in that, but it does keep the headers having consistent, predictable and expected locations.
Awesome advice! Thank you!
I made directories of GLEW and freeGLUT in my C:\...\Program Files(x86)\. I added the .lib files to the additional dependencies (I used the entire file name, i.e. C:\...\GLEW\lib\glew32.lib, is this necessary?) and the include folders to the VC++ Include Directories.
It doesn't seem to like to include freeglut.h before glew.h (error: "gl.h is included before glew.h".) However, if you switch the order of includes, then there is no error in the build. As well, glut.h will not build with either glew.h or freeglut.h. I think that makes sense, because freeglut.h is a replacement for glut.h. Is that correct?
When I test out if everything is building properly and then I run the program with an int main() method, including a system pause (otherwise empty), I get a whole bunch of errors in my debug. These errors do not interfere with the program as far as I can tell, but then again I'm really not calling any functions. The errors pertain to not finding certain *.dll files. For example, the debug will say "'GLFramework.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll', Cannot find or open the PDB file." I looked up ntdll.dll, and I found that antivirus software will remove this file if it becomes corrupted. Should I be concerned that these *.dll files are not being found and should I replace them?
What is the recommended next step/ is there a square one type tutorial that I can start learning from if I want to learn freeGlut/GLEW?
#5 Members - Reputation: 108
Posted 20 April 2012 - 05:31 PM
Personal preference I guess. I have a directory called libraries within which they sit. My applications are in the originally named "applications" at the same level as the libs. I have a single solution called 3rdpartylibs, that builds all libraries together and puts the resulting libs and dlls into a directory called Built/r or Built/d. All of my applications link against Built/r or Built/d. This way I can prevent the total randomness that tends to happen when the second law of thermodynamics applies itself to your hard drive ;).
#6 Members - Reputation: 3828
Posted 20 April 2012 - 05:36 PM
The PDB file stuff can be safely ignored, and everything else sounds like expected behaviour. Learning GLUT (for FreeGLUT) and GLEW is not really something you do. In the case of GLEW it's just making sure that you call glewInit in the right place (i.e after you context is created); there's nothing else you really need to do. GLUT has a few simplistic Window/etc management functions, but for a serious program you'd use something else - the purpose of GLUT is to provide a simple framework for tutorials and examples so that the OS-specific code doesn't get in the way of the GL code.
It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.
#7 Members - Reputation: 126
Posted 20 April 2012 - 06:28 PM
for a serious program you'd use something else - the purpose of GLUT is to provide a simple framework for tutorials and examples so that the OS-specific code doesn't get in the way of the GL code.
What would you use instead?
I thought GLUT was pretty powerful.
#11 Members - Reputation: 1153
Posted 22 April 2012 - 11:58 PM
I never touch system directories (like Program Files or Windows) for headers on libs for my C++ projects. It is a bad practice to mess with system folders.
I put them in same folder where is my project. I usually create folder with project name (for example - GLFW). Under it I create folders "include", "lib" and "bin". In those I put the needed files. And in project properties I reference libs and includes by relative path from the location of project file. This way it's very easy to store project in source control system (svn, git, ...) and it is easy to give project to friend (or even to myself on different computer) just by zipping up the folder instead of telling him to mess with his system directories.
I put them in same folder where is my project. I usually create folder with project name (for example - GLFW). Under it I create folders "include", "lib" and "bin". In those I put the needed files. And in project properties I reference libs and includes by relative path from the location of project file. This way it's very easy to store project in source control system (svn, git, ...) and it is easy to give project to friend (or even to myself on different computer) just by zipping up the folder instead of telling him to mess with his system directories.
