I've built an OpenGL program with my glu and gl header files default included in windows 7 professional edition. Now, I've bought a book that describes OpenGL game development. The author of this book said, I have to include the glew header into my project. After I've done this I got some unresolved external symbol errors.
So, now I'm really confused.
I've worked earlier with glBegin and glEnd statements in my program. Now I've to work with glBindBuffers and glGenBuffer etcetera, but I get the unresolved external symbol errors, like that:
1>cWindows.obj : error LNK2001: unresolved external symbol __imp___glewBindBuffer
1>cMdlLoader.obj : error LNK2001: unresolved external symbol __imp___glewBindBuffer
1>cMdlLoader.obj : error LNK2001: unresolved external symbol __imp___glewBufferData
1>cMdlLoader.obj : error LNK2001: unresolved external symbol __imp___glewGenBuffers
Is there anyone here who can explain the difference between these header files and what I have to do with them?
I goggled many times, but on different sites there are much more confusing words like "glee" or "glut".
You're mixing up 3 different things here:
OpenGL
the GL Utilities (GLU) which are not part of OpenGL
and the GL Extension Wrangler (GLEW)
GLEW and GLU are completely different things and you can not replace one with another.
GL/gl.h are the base OpenGL headers, which give you OpenGL-1.1 function and token declarations, any maybe more. For anything going beyond version 1.1 you must use the OpenGL extension mechanism. Since this is a boring and tedious task, that has been automatized by the GLEW project, which offer all the dirty details packed up in a easy to use library. The declarations of this library are found in the header file GL/glew.h. Since OpenGL extensions don't make sense without basic OpenGL, the GLEW header implicitly includes the regular OpenGL header, so as of including GL/glew.h you no longer need to include GL/gl.h.
Then there's GLU, a set of convenience methods, which BTW are seriously outdated and should not be used in any modern OpenGL program. There's no modern GLU, so just forget about it. Anyway, it's declarations are made available by the header GL/glu.h (the one you were asking about).
The errors you get have nothing to do with include files though. Those are linker errors. Just including the declarations is only half of the job. The other half is linking the actual definitions and those are not in the header by the library file; libglew.so or libglew.a on a *nix OS, glew.lib or glew32.lib or glews.lib or glew32s.lib on Windows. If not using the static versions (those without the 's') you also must have installed the right DLL.
So to use GLEW you need to include the header and add it to the list of libraries in the linker options. Also you must call glewInit(); once you've obtained a OpenGL context in your program.
gl: This is the base header file for OpenGL version 1.1. That means if you want to use any functionality beyond version 1.1, you have to add any extension library on this.
glew: OpenGL Extension Wrangler Library. This is a cross-platform library for loading OpenGL extended functionality. When you initialize this library, it will check your platform and graphic card at run-time to know what functionality can be used in your program.
glu: This is OpenGL utilities library, which has been not updated for long time. Don't need to use this header file.
glut: OpenGL Utility Toolkit for Windowing API. This is good for small to medium size OpenGL program. If you need more sophisticated windowing libraries, use native window system toolkits like GTK or Qt for linux machines.
glfw: OpenGL Frame Work. Another multi-platform library for creating windows and handling events. FreeGlut can be used as an alternative. glfw is designed for game development.
glm: OpenGL Mathematics. It helps implementing vectors and matrices operations.
I am very new to OpenGL stuff, so please correct me if I'm wrong.
Related
I've got a C++ Builder (Rad Studio Berlin) project setup to use Direct2d. Canvas drawing works just fine with the TDirect2DCanvas which would indicate Direct2D is linking properly. Everything renders smoothly. However, I need to use a matrix. I get linking error when I try to. For example, when try I:
canvas->RenderTarget->SetTransform(D2D1::Matrix3x2F::Rotation(15.0, D2D1PointF(100, 100)));
...I get the following linking error:
[ilink32 Error] Error: Unresolved external 'D2D1MakeRotateMatrix' referenced from C:\DP\TRUNK\SRC\CLIENTSIDE\APPLICATIONS\VIEWER\WIN32\DEBUG\MIMAGE.OBJ
C++ builder was supposed to already be setup to link against direct2d if I just include the headers. Can anyone help me link against the appropriate files in the C++ Builder way?
I found the solution from a different source. Here it is:
After some research, this issue has not been determined to be a bug.
For many of the standard Windows API functions, the IDE will add the correct library automatically so that the dependencies on the function references will be satisfied. With DirectX (which is somewhat uncommonly used), the IDE does not automatically supply the library which corresponds to the header file, so this is causing the unresolved linker errors.
The solution is to either (as I mentioned previously) add the D2D1.lib to the project, or statically reference it in code:
// as long as D2D1.lib is on the library search path, it should be found
#pragma comment(lib,"D2D1.lib")
Some developers add the above line of code to their headers and so all you need to do is include the header and all is well... the DirectX team did not do this and hence the unresolved linker errors.
Hope this clarifies the issue,
I am writing an OpenGL based game. It includes just these two libraries: glew, glfw3. In order to run it the user must obviously have OpenGL installed, an assumption which I'd like to bypass.
I've gathered all the appropriate binaries inside the game directory and tried linking to these libraries locally but the compiler claims undefined reference to all their functions. Am I doing something wrong or is it just impossible? I'm using Windows but it fails on Linux for the same reason.
OpenGL is not a library you install, it's an API that's implemented as part of the driver. Your compiler complaining about symbols not resolving is completely unrelated to the situation on the end user's computer. And in your case it simply sounds that you did not tell the compiler / linker which libraries and API interfaces to link into your program binary; your compiler is hence complaining, that some of the internal references don't redolve.
So here it goes: OpenGL is not something you ship with your program, it's part of the graphics drivers and your program must use whatever OpenGL version is installed on the user's machine. For this you dynamically link against libGL.so by passing the compiler-linker option -lGL.
GLEW is a helper library that post-loads dynamically all OpenGL functions not found in the system OpenGL ABI, which hence are not exported through the public symbol table of libGL.so. Rather they're to be loaded dynamically using glXGetProcAddress – a rather tedious task. Be advised that GLEW has some serious issues when it comes to OpenGL-3 and later core profiles.
GLFW is a simplistic framework library for setting up a window having an OpenGL context.
GLEW and GLFW are safe to link statically with your program, and I recommend you do that. Instead of using the -l… flag, add libGLEW.a and libGLFW.a to the list of source files / compilation units to be linked.
http://opengl.org/ and http://www.khronos.org/ seems to be currently unavailable. Is there any good alternative mirror sites?
I am looking for OpenGL 4.4 Libraries and Includes download for VC.
OpenGL is not a library, it's an API specification. What you can download at http://opengl.org are just the specification documents and reference C include headers. But there are no library downloads there because, well, OpenGL is not a library.
The actual OpenGL implementation ships as part of your GPU's driver. That's also what ultimately determines which version of OpenGL you can use: The GPU on the system the program is executed on. The major OpenGL version designates the hardware class. A OpenGL-3 class GPU can not do OpenGL-4 (but a OpenGL-4 can do OpenGL-3 of course).
For all practical means there's nothing you need to download or to install to get working with OpenGL. This is different from DirectX where you need a special SDK. OpenGL has been included into the ABI (Application Binary Interface) of the major operating systems, including Windows, and hence the standard headers ship with compilers targeted at this system.
In your case you'll find the OpenGL base headers being preinstalled with the default installation of Visual-C++.
However newer versions of OpenGL require additional tokens and functions to be defined. That's where extension headers come into play. But since there's no change in the ABI, the actual functions do not come as part of a library but must be loaded at runtime using wglGetProcAddress for each function.
Since this is a tedious process there are OpenGL extension loader wrapper libraries, like GLEW (available at http://glew.sf.net) which package up the extension headers and some library code to do the whole loading thing with just a single command. Since there are things to consider like namespace pollution and interoperability with other means of extension loading, GLEW patches into the regular OpenGL headers with preprocessor macro definitions, so that all compilation units that include GLEW just use GLEW. This makes it look like GLEW replaces the regular headers and interface libraries, but in reality it just builds on and defers to them.
Well, usually you want to use glew or a similiar library in order to get the OpenGL functions. You can grab a copy of glew here: http://glew.sourceforge.net/. The libraries should come bundled with VC so you simply add OpenGL32.lib to your linker's additional dependencies.
Actually, I know it's a popular linking problem, which regularly can be resolved by adding #pragma(lib, "glu32.lib") or adding glu32.lib in Visual studio configuration.
However, my problem is strange and solutions above is useless.
I added some extra files containing OpenGL functions like gluPerspective and gluBuild2DMipmaps to the CUDA project, the VolumeRender, which is from CUDA SDK.
After compiling, I found those extra files would occur the Unresolved External Symbol error for glu functions. However, when I put these glu functions into the original Cpp file, it works fine.
I have ever tried two solutions above but useless. Could anyone give me a hint to solve this puzzle?
Finally I gave up. I tried to add the CUDA part into the OpenGL projects. It worked fine!
I am trying to use geometry shaders in my OpenGL application that is currently using Freeglut, and I am trying to use GLEW to do that because as I understand it, the geometry shader functionality is in an extension. My include order is as follows:
#define GLEW_STATIC
#include <glew.h>
#include "freeglut.h"
However when I do this I get lots of linker errors like the following:
error LNK2001: unresolved external symbol ___glewAttachShader
I do not receive any errors when I only use the basic OpenGL functionality (that it, things that are not in the extensions) so I know that the compiler is finding all the "basic" libraries like glu32 etc. I am using Visual Studio 2008. Any suggestions?
It's a linker error that says it did not find a glew entrypoint.
Link against the glew library (you did not see the error before because you did not use any extension, I assume).
Edit:
Actually, this is directly related to your usage of "GLEW_STATIC".
From the GLEW page:
On Windows, you also have the option of adding the supplied project file glew_static.dsp to your workspace (solution) and compile it together with your other projects. In this case you also need to change the GLEW_BUILD preprocessor constant to GLEW_STATIC when building a static library or executable, otherwise you get build errors.
What this says is that it is your responsibility to build and include the glew source files when you use the GLEW_STATIC setup.