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.
Related
Why do I need both the libopengl32.dll and the libglew32 libraries when compiling an OpenGL program? What's the difference between the libraries and why do I need both?
You do not (always) need both the libopengl32.dll and the libglew32 libraries when compiling an OpenGL program. You need both when compiling a GLEW program (which implies also being an OpenGL program since GLEW builds upon OpenGL). For some people, this difference is academic since they would never consider writing an OpenGL program without the convenience of GLEW (et al.). However, GLEW is not required by OpenGL.
Your OpenGL library is the base upon which your GLEW library depends. You can use OpenGL without GLEW, but you cannot use GLEW without OpenGL. If your program uses GLEW, then you need to link your GLEW library because you are using it, and you need to link your OpenGL library because GLEW (and probably your code as well) uses that. If you are using pure OpenGL with no elements of GLEW, you need just to link your OpenGL library.
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.
I have missing opengl32 library (more details: mingw32 w64 missing OpenGL32 lib). I have several questions related to this library:
Why I need opengl32 static library ( I have .dll)?
Why video card vendors does not provide this library?
Who should provide it?
Is there a source code of opengl32 library?
Why I need GLEW or other GL library implementations (to use all features of OpenGL) if there is opengl32? Why opengl32 cannot have all required GL implementation?
Why I need opengl32 static library ( I have .dll)?
It provides the symbol table for the linker. The symbol table tells the linker which functions are provided by the library, so that the linker knows how to tie the symbols used in the program, to the libraries linked.
Note that on other OSs than windows, the "DLL" does also provide the symbol tables.
Why video card vendors does not provide this library?
Because the library is part of the OS interfaces to the driver system
Who should provide it?
The DLL: The OS vendor.
The symbol table library: The compiler vendor.
Is there a source code of opengl32 library?
OpenGL itself is just a specification. What you have on your computer is a implementation and a interface. The interface is part of the OS. Hence on closed source OSs there is no source code available, but on open source OSs there is.
Why I need GLEW or other GL library implementations (to use all features of OpenGL) if there is opengl32?
opengl32.dll is just a interface to the driver system. This interface needs to be the smallest common denominator of OpenGL features, so that a wide range of OpenGL versions and capabilities can be offered through a common interface. However you also want to be able to access newer, and bleeding edge features, for which the extension mechanism exists.
Why opengl32 cannot have all required GL implementation?
opengl32.dll is part of the operating system and if it were part of the OS, then every new version of OpenGL would require a OS update. This is, in fact, the situation of MacOS X.
Also the OpenGL implementation is part of the driver, not the DLL.
It's not a static library, it's the library to dynamically link to the DLL.
Because it's a part of the OS, more or less. The symbols exported from OpenGL32.dll tend to be standard (a particular set of gl... functions) and Microsoft-specific (wgl ones at least). The publicly-known ones don't vary between vendors.
Microsoft does provide it, with their compilers. Any other compiler vendor should as well, since libs can be somewhat compiler-specific.
Mesa is an open-source OpenGL implementation, so the closest you'll get.
You don't, you can get the strings and function pointers manually, it's just extremely tedious. GLEW et al do most of the feature-checks and initialization for you. They don't do anything you can do directly with OpenGL32.dll, but they do make life a lot easier.
I want to get ( or build from source) OpenGL library that is statically linked to the crt on Windows.
I don't want my executable to require OPENGL32.dll.
My compiler is Visual C++ 9.
Where do I begin? The OpenGL website directs me to this wiki http://www.opengl.org/wiki/Getting_started
But that wiki tells me "In all three major desktop platforms (Linux, MacOS X, and Windows), OpenGL more or less comes with the system".
I am on Windows. Is this statement true. How do I verify this?
Statically linked OpenGL library on Windows
I don't want my executable to require OPENGL32.dll.
Impossible. End of story. opengl32.dll is provided by microsoft and may be changed after each system update. So you can't static-link it - it is a system component.
You can only static link with mesa3d which emulates OpenGL on CPU. However, it is not fully compliant to OpenGL, so you can get unexpected problems, and you'll still require several system dlls. (my bet is gdi32.dll) for your application. Also, performance will be very bad compared to normal OpenGL.
I believe what you are saying is that you don't want to be forced to make your application link with the C Runtime libraries dynamically (i.e. Multithreaded DLL or Multithreaded Debug DLL in the Properties/C++/Code Generation/Runtime Library setting).
Since OpenGL is a system provided .DLL, you are still free to choose Multithreaded or Multithreaded Debug (both choices statically link to the C Runtime) for your Runtime Library when using OpenGL.
I want to create a program that could work on any computer without the source code, How is that possible? and does it make any difference if I used OpenGL in the Program?
You cannot code a program in C++ that would work on any computer without giving your source code to be compiled.
For example, you could perhaps code in C++ a program, and compile it and build an executable which works on Windows x86-64, but that executable won't work on Linux (or MacOSX), and it won't work on ARM (e.g. Android phones) unless you consider using emulators
If you are developing your code with Visual C++ you may need to consider two options:
Make sure you link all libraries statically.
Install on the target computers along with your program Microsoft Visual C++ Redistributable Package corresponding to the Visual C++ version you use like the one at http://www.microsoft.com/download/en/details.aspx?id=5555. Some installer generating software will make it for you automatically.
Normally you would link your object file with some sort of a platform dependent loader. This loader loads your object and does all the stuff to start it from memory. Normally you can tell your compiler to link your object file and compile a blob. OpenGL is a powerful API and is usually distributed as a.dynamic linked library and is linked at runtime to your program. If I remember you just have to make sure the dll is where you want it and load the dll in your program from start.
Your C++ program is compiled and linked into an executable before it is run. You should be able to find that executable in a Debug or Release subfolder of the folder containing your project.
OpenGL, if you're not using GLUT or similar libraries, should just come with Windows and pose no additional problems. If you do use GLUT, it's enough to bundle the .dll file with your application.
In any case, the source code won't be necessary.
I want to create a program that could work on any computer without the source code, How is that possible? and does it make any difference if I used OpenGL in the Program?
By compiling and linking it into an executable. As long as you're not using some interpreted language (like Python, Ruby or such) you're presented with an executable inevitably. The biggest problem you may/will run into is dependencies on libraries. However those are linked into a binary as well. So what you're going to ship will be just a .exe; and some .dll maybe. Usually you'd wrap this in a installer package for deployment to the end user. Installers are created with something like the "NullSoft Installer System" (NSIS).
OpenGL itself is just a API, provided by a system library. So you don't ship OpenGL with your program, but expect the user to have it installed on the system (which will be the case if he installed the graphics drivers).