Dynamic versus Static Libraries
Author
Can someone explain the difference? Static libraries are linked at compile time while dynamic libraries are generally hooked at runtime, right? The only reason I could see for using a DLL over a static library is code reuse within or between programs...just use 1 DLL instead of having the code linked every time.
Also, does anyone have any good articles on creating and loading DLLs in your code for MacOSX? I know it uses the dlfcn library (or, a wrapper at least) -- but for some reason it finds the handle but not the symbol (aka, dlsym doesn't work). Any ideas how to figure this out?
Thanks!
Another good reason is that if there's a bug in the code contained in one DLL, then only the one DLL needs to be replaced to update all of the programs that use it. With static libraries, every program that used the library would have to be recompiled and linked with the fixed library.
Quote:Original post by visage
Can someone explain the difference? Static libraries are linked at compile time while dynamic libraries are generally hooked at runtime, right? The only reason I could see for using a DLL over a static library is code reuse within or between programs...just use 1 DLL instead of having the code linked every time.
Thanks!
That's the exact purpose of DLL: sharing code among applications. Static libraries embed the code in your application (they are linked at link time, not compile time. This is a different stage, performed with a different tool - ld if you are a gcc-freak, link.exe if you use MSVC).
Regards,
Author
How do DLLs affect porting? I would like to write some software using SDL and OpenGL to make it as portable as possible -- but I am writing it on a mac, which uses dylibs and dlopen (*nix uses dlopen...). However, as far as I know, Windows certainly does not. Would it be best for me to avoid a dynamically linked engine design if I desire to port? Or would I just have to have the DLLs compiled on each target platform and have different loading code for each?
Also, do people who generally use DLLs load them at runtime? Half-Life used a run-time DLL system, right? Thats what made the mods possible, right?
Thanks!
Also, do people who generally use DLLs load them at runtime? Half-Life used a run-time DLL system, right? Thats what made the mods possible, right?
Thanks!
Quote:Original post by visage
How do DLLs affect porting? I would like to write some software using SDL and OpenGL to make it as portable as possible -- but I am writing it on a mac, which uses dylibs and dlopen (*nix uses dlopen...). However, as far as I know, Windows certainly does not. Would it be best for me to avoid a dynamically linked engine design if I desire to port? Or would I just have to have the DLLs compiled on each target platform and have different loading code for each?
Thanks!
If you want to go the DLL way: encapsulate loading code. The technique is cross platform, but the implementation is not, therefore the way to go is to encapsulate the code that is used to load/unload the DLL and fetch the symbols adresses.
Now, you can still decide to statically link your code to your application. This is not really important.
Regards,
You can't just change the library and replace the DLL and hope it works; that will only work if you've maintained binary compatibility (ABI) between the old and new versions.
For a game engine or something similar, with a complicated interface, the probability of the interface staying the same between (even close) versions is pretty low - which would break ABI compatibility.
The kind of thing I'm thinking about, is adding a member to a structure (or class) - which might appear to work (i.e. no link errors) but may then go horribly wrong at runtime.
I'd always favour static linking against your libraries, unless you *know* you're going to want to link to different implementations which are unknown at compile-time - which is, for the most part, unlikely for parts of a game.
Mark
For a game engine or something similar, with a complicated interface, the probability of the interface staying the same between (even close) versions is pretty low - which would break ABI compatibility.
The kind of thing I'm thinking about, is adding a member to a structure (or class) - which might appear to work (i.e. no link errors) but may then go horribly wrong at runtime.
I'd always favour static linking against your libraries, unless you *know* you're going to want to link to different implementations which are unknown at compile-time - which is, for the most part, unlikely for parts of a game.
Mark
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
