0

I've been following some tutorials for using some C libraries for game development on windows. When using some opengl libraries (freeglut, glew), I just need to compile using "cl file.c", and if I have the right dll files in the current directory, it will compile and run fine.

But for SDL, I have to explicitly provide the lib files, e.g. "cl sdlprog.c SDL2.lib SDL2main.lib". I also have to indicate that it's a console program with "/link /subsystem:console".

Why do I need to do these things for SDL? The opengl program compiles fine without any mention of the lib files.

I made sure all of the lib files are in the correct place. They're in the same place I put the opengl lib files.

J. Czekaj
  • 31
  • 7
  • The mechanics for how dependencies are consumed vary widely from SDK to SDK. Ex: the glew build you mention, for example, clearly states on their website that, when using a shared library configuration, *"Remember to link your project with glew32.lib, glu32.lib, and opengl32.lib on Windows and libGLEW.so, libGLU.so, and libGL.so on Unix (-lGLEW -lGLU -lGL)."* Regarding your question, the simple answer is because that's how the SDL authors chose to provide their library for consumption, and they're probably [the best source to ask](https://discourse.libsdl.org/). – WhozCraig Jun 10 '19 at 00:42
  • Could you post part of your *sdlprog.c* file? I'm interested on the preprocessor macros (lines that start with a ***#***). – CristiFati Jun 13 '19 at 11:56
  • @CristiFati I've deleted it since then, because it was just a tiny test program that initialised sdl. But I'm pretty sure it was just a #include , the reason the SDL2 is there, is because I put sdl's headers in include\SDL2. – J. Czekaj Jun 14 '19 at 19:57
  • You should provide a *MCVE* ([\[SO\]: How to create a Minimal, Complete, and Verifiable example (mcve)](https://stackoverflow.com/help/mcve)) which should contain the code, the command to build it, the error, and the command that succeeds. – CristiFati Jun 15 '19 at 10:12

1 Answers1

2

Some libraries are dynamically loaded and accessed through function pointers. In those cases, libraries do not have to be explicitly linked at compile time. Other libraries can be statically linked where they do not require dynamic loading but the linking is done at compile time. Then there are some libraries that are linked compile time but they just provide an easy to use interface for the dynamic loading process. A good example of this is the import address table in Win32 PE files. A call to NtTerminateProcess for example is found in ntdll library. You can call NtTerminateProcess dynamically by calling LoadLibrary and GetProcAddress or you can choose to link it compile time which will create the interface for you; However, ntdll will still need to be dynamically loaded at runtime. Linking it compile time was not static, it just merely allowed you to call NtTerminateProcess without the use of LoadLibrary/GetProcAddress.

So the question comes down to the difference between static linking, which what opengl is doing. Or dynamic linking which is what sdl is requiring. And as I mentioned earlier dynamic loading which at runtime allocates memory for the module to be loaded and loads it into an address specified by the OS. There's already a post that slightly covers this :

Difference between static linking and dynamic linking

difference between dynamic loading and dynamic linking?

With static linking, if your library ever changes you will need to recompile the binary. In the case of dynamic linking, you do not have to recompile the binary only the dlls.

Irelia
  • 3,407
  • 2
  • 10
  • 31