I know that SFML is a 2D OpenGL library, but why does programs using SFML not require opengl32.dll or glew.dll?
I created library.lib and library.dll, which use external functions from GLEW and FreeGLUT. Then, I created test_library.exe and linked my library to this program.
After compiling (successfully) I realized that this program requires some DLLs from my library.
How do I use external symbols from missing DLLs just like SFML?
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.
I have just started using Emscripten and would like to start using GLFW and other libraries. I am completely lost on how to build, link, and use other libraries with Emscripten.
I have tried following the instructions on the Emscripten site but have they haven't helped me any.
http://kripken.github.io/emscripten-site/docs/compiling/Building-Projects.html#using-libraries
Is there any place with detailed instructions on how to use libraries with Emscripten? Or specifically GLFW?
Emscripten provide itself very few libraries. Those libraries are the minimum to get some OperativeSystem functionality on emscripten C++ code (audio, input, video)
libc: standard library for C
libc++: standard library for C++
SDL: SimpleDirectmediaLayer (SDL 1.X a opensource cross-platform project)
GLES2: OpenGL ES 2 API
GLFW: GLFW 2.X
For example, the standard way to include OpenGLES2 in Emscripten is:
#include <GLES2/gl2.h>
While to include GLFW:
#include <GL/glfw.h>
There's some crap in that, because if you want to use the more recent version of GLFW you just can't because Emscripten provides only 1 version of the library and you have to stick with that (unless Emscripten do a update for that and you update Emscripten).
You can compile libraries for emscripten only if that libraries can be compiled using one(or more) of the libraries listed above. (or if you know how to wrap javascript funciontalities and expose them through C interface)
Also, try to avoid templates only libraries when using Emscripten, they literally generate a lot of bloat code you could easily increase executable size by several MBs: This is a problem if you were already using Boost or UBLAS.
Since GLFW is not one of the libraries that are automatically linked, you should link it with:
-lglfw
You can find an example OpenGL project using Emscripten here:
https://github.com/QafooLabs/emscripten-opengl-example
you can inspect linker flags by opening the makefile
I have just started using Emscripten and would like to start using GLFW and other libraries. I am completely lost on how to build, link, and use other libraries with Emscripten.
I have tried following the instructions on the Emscripten site but have they haven't helped me any.
http://kripken.github.io/emscripten-site/docs/compiling/Building-Projects.html#using-libraries
Is there any place with detailed instructions on how to use libraries with Emscripten? Or specifically GLFW?
Emscripten provide itself very few libraries. Those libraries are the minimum to get some OperativeSystem functionality on emscripten C++ code (audio, input, video)
libc: standard library for C
libc++: standard library for C++
SDL: SimpleDirectmediaLayer (SDL 1.X a opensource cross-platform project)
GLES2: OpenGL ES 2 API
GLFW: GLFW 2.X
For example, the standard way to include OpenGLES2 in Emscripten is:
#include <GLES2/gl2.h>
While to include GLFW:
#include <GL/glfw.h>
There's some crap in that, because if you want to use the more recent version of GLFW you just can't because Emscripten provides only 1 version of the library and you have to stick with that (unless Emscripten do a update for that and you update Emscripten).
You can compile libraries for emscripten only if that libraries can be compiled using one(or more) of the libraries listed above. (or if you know how to wrap javascript funciontalities and expose them through C interface)
Also, try to avoid templates only libraries when using Emscripten, they literally generate a lot of bloat code you could easily increase executable size by several MBs: This is a problem if you were already using Boost or UBLAS.
Since GLFW is not one of the libraries that are automatically linked, you should link it with:
-lglfw
You can find an example OpenGL project using Emscripten here:
https://github.com/QafooLabs/emscripten-opengl-example
you can inspect linker flags by opening the makefile
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.
I am using SFML, and I am building an application in Code::Blocks and mingw32. I have have added the SFML libraries (sfml-whatever.a) to my project, and it runs nicely.
BUT iIrc, the static libraries get 'compiled' into the executable. If this is so, then why do I have to place all the SFML DLL's next to the executable for it to run anywhere outside of Code::Blocks? And if I were to somehow 'dynamically link' the DLL's from within Code::Blocks to my project, (I don't know how to do that), would I still have to ship my executable with all the .a files for it to run properly?
Thanks in advance, I am not quite familiar with libraries, static or dynamic. If it makes any difference, I am working on Ubuntu linux, and I am using mingw32 for cross-compiling.
With SFML you can link statically to their libraries as mentioned in the comments above. This way its all compiled into the executable and you won't need to ship it with the DLL's. How this is done depends on whether you are using SFML 1.6 or 2.0.
1.6 doesn't require any preprocessor definitions, but 2.0 requires you to build a solution/makefile using cmake for your compiler and then #define SFML_STATIC in your preprocessor definitions.
In this case, the static libraries simply contain the code that interfaces to the dynamic libraries, it's not the actual library code.