Hello,
I have some little questions about compiling and linking OpenGL programs under Windows. I have downloaded the code examples from the book "OpenGL super bible" and all the projects compile, link and run fine. I just don't understand WHY.
1. Lets say I have a source file foo.cpp which includes a header with a relative path: #include "../../shared/gltools.h"
Is this path relative to the solution file (.sln) of the project or relative to the .cpp file where the include stands?
2. The project has one .cpp file which uses OpenGL and GLUT functions. Nonetheless the project does NOT link to any openGL libs. I expect some entries like OpenGL.lib or glut.lib under "linker->input->additional dependencies", but there are no entries! How can this project link, when it does not add the libraries?
Compiling/linking OpenGL
Those are not OpenGL related questions. You are probably now to MS Visual Studio. There are several ways to include libraries. In the case of SuperBible samples, libraries are included in the project file as source files. There are their relative path in .vcproj files. Usually freeglut and gltools are included. The path should be defined relative to the project file, not the solution file.
Quote:Original post by schupf
Hello,
I have some little questions about compiling and linking OpenGL programs under Windows. I have downloaded the code examples from the book "OpenGL super bible" and all the projects compile, link and run fine. I just don't understand WHY.
1. Lets say I have a source file foo.cpp which includes a header with a relative path: #include "../../shared/gltools.h"
Is this path relative to the solution file (.sln) of the project or relative to the .cpp file where the include stands?
dont do this. If they have done this, they are a bunch of spanners who dont know how to use VS properly.
Go to project properties -> General Settings -> C/C++ / General and add wherever your "shared" folder is to "Additional include directories." Then, use #include "gltools.h"
Quote:
2. The project has one .cpp file which uses OpenGL and GLUT functions. Nonetheless the project does NOT link to any openGL libs. I expect some entries like OpenGL.lib or glut.lib under "linker->input->additional dependencies", but there are no entries! How can this project link, when it does not add the libraries?
You must add those yourself - its a mystery to me how it can link without any linker inputs. Are you sure it doesnt have any?
Author
Quote:Original post by speciesUnknownQuote:Original post by schupf
2. The project has one .cpp file which uses OpenGL and GLUT functions. Nonetheless the project does NOT link to any openGL libs. I expect some entries like OpenGL.lib or glut.lib under "linker->input->additional dependencies", but there are no entries! How can this project link, when it does not add the libraries?
You must add those yourself - its a mystery to me how it can link without any linker inputs. Are you sure it doesnt have any?
As far as I know there are two ways in VS to add a library: Via project properties (Linker->Input->Additional dependencies) or via #pragma directive. The superbible project neither defines any libs in the project properties nor does it define any #pragma directive. Yet it uses OGL and GLUT functions and links perfectly.
If you are interested you can download the windows projects here: http://www.starstonesoftware.com/OpenGL/fourthEdition.htm (Source with pre-built binaries (Windows))
Anyone has an idea why these projects are compiling and linking without any errors?
Are any libraries at all included, whether gl or not?
There could be another library like "glSuperBible.lib" which includes the opengl.lib and is contained in another library. I don't know if thats possible but somewhere it is obviously linked in. So just don't worry about it. If you have your own projects, then link them normally.
There could be another library like "glSuperBible.lib" which includes the opengl.lib and is contained in another library. I don't know if thats possible but somewhere it is obviously linked in. So just don't worry about it. If you have your own projects, then link them normally.
Author
I think I just have found the solution!
As I said in my start posting the .cpp file includes a header file (../../shared/gltools.h). This header file includes the file "glut.h" and this header file includes "freeglut_std.h" and this header has the following lines:
I guess thats the reason why it links even though there are no input libs specified in the project.
Some last questions:
1. When I want to use OpenGL all I have to link is opengl32.lib, haven't I? This glu32.lib is optional and only needed when I use functions with prefix "glu"?
2. I never downloaded any OpenGL SDK and I have found such a opengl32.lib on my system (Win7). But how do I know if this "preinstalled" lib suits my requirements? I mean since I have installed Win7 last year the lib is obviously kinda old and how do I know if this lib supports OpenGL 4.x functions? Shouldn't it be necessary to regularly download new OGL libs and dlls?
As I said in my start posting the .cpp file includes a header file (../../shared/gltools.h). This header file includes the file "glut.h" and this header file includes "freeglut_std.h" and this header has the following lines:
# if FREEGLUT_LIB_PRAGMAS# pragma comment (lib, "glu32.lib") /* link OpenGL Utility lib */# pragma comment (lib, "opengl32.lib") /* link Microsoft OpenGL lib */# pragma comment (lib, "gdi32.lib") /* link Windows GDI lib */# pragma comment (lib, "winmm.lib") /* link Windows MultiMedia lib */# pragma comment (lib, "user32.lib") /* link Windows user lib */# endifI guess thats the reason why it links even though there are no input libs specified in the project.
Some last questions:
1. When I want to use OpenGL all I have to link is opengl32.lib, haven't I? This glu32.lib is optional and only needed when I use functions with prefix "glu"?
2. I never downloaded any OpenGL SDK and I have found such a opengl32.lib on my system (Win7). But how do I know if this "preinstalled" lib suits my requirements? I mean since I have installed Win7 last year the lib is obviously kinda old and how do I know if this lib supports OpenGL 4.x functions? Shouldn't it be necessary to regularly download new OGL libs and dlls?
1. Yes, that's correct. There's no harm in linking to glu32.lib though; if you don't use any functions from it no extra code will be included in your exe.
2. There is no lib for Windows that supports any OpenGL versions greater than 1.1 and the one that comes with your compiler is the one you should use. For versions higher than 1.1 you need to use the extension machanism to get entry points.
2. There is no lib for Windows that supports any OpenGL versions greater than 1.1 and the one that comes with your compiler is the one you should use. For versions higher than 1.1 you need to use the extension machanism to get entry points.
If you plan on using post-1.1 features (and you should or probably have to) it is recommended to use the OpenGL Extension Wrangler library which handles all extension entry points for you.
I just want to shoot in a question here: Is glew unnecessary on other OS-s than Windows? It seems implied since most say "this is necessary on Windows" but I have not done any OpenGL under any other OS than Windows.
I just want to shoot in a question here: Is glew unnecessary on other OS-s than Windows? It seems implied since most say "this is necessary on Windows" but I have not done any OpenGL under any other OS than Windows.
I've only ever used SDL on Linux, which comes with it's own headers and libs (meaning that you at least don't need to define a lot of stuff) but does need a call to SDL_GL_GetProcAddress.
Personally I would be of the opinion that the extension mechanism kinda requires getting the entry points to confirm that they exist. For example, an older driver may support VBOs but not occlusion queries, so it wouldn't have entry points for occlusion queries. Also, I've found in the past that a certain manufacturer's drivers (naming no names but you can probably guess) only supported the -f versions of some functions and not the -i versions. If it happened once it can happen again, so I would still say that you should confirm the entry points. Your headers and libs are not your drivers after all.
Personally I would be of the opinion that the extension mechanism kinda requires getting the entry points to confirm that they exist. For example, an older driver may support VBOs but not occlusion queries, so it wouldn't have entry points for occlusion queries. Also, I've found in the past that a certain manufacturer's drivers (naming no names but you can probably guess) only supported the -f versions of some functions and not the -i versions. If it happened once it can happen again, so I would still say that you should confirm the entry points. Your headers and libs are not your drivers after all.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
