• Advertisement
Sign in to follow this  

Where is the best place to put your .lib, .dll and gl header files?

This topic is 2127 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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 ;).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
I'm using GLU to bring in all the required extensions and then doing all of the windowing stuff myself. SFML is a pretty good library to use. I think the trouble with GLUT is that it hasn't been actively maintained for a very long time.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement