static linking

2013-11-11

Why do I not like static linking?
In the most simple case, there is not much difference. Assume my game looks like this:

• server.c
• client.c
• game.c
• library.c

The game depends on library, and both client and server depend on game as well as library. When building with dynamic linking, I get this:

• server.exe
• client.exe
• game.dll
• library.dll

With static linking I get this:

• server.exe
• client.exe

Now there's a first small advantage. In the shared case, the code from game.dll and library.dll is included in both exes, so in the dynamic case I save a few bytes. The disadvantage of having more files outweighs this though.
But now, how are we building in the case of static linking. First, we get an object file for each .c file. After that we build static libraries:

• libgame.a
• liblibrary.a

But wait, we said game depends on library. So now actually libgame.a already contains a copy of the code in liblibrary.a it uses. Now we create server.exe, which depends on both game and library. What if it needs a function which is also used by library? Does it get another copy, or are both using the same one?
The answer to me is that I'm not sure. I once had it happen that game was using one version (which was outdated) of library and server was using another version. Which led to impossible bugs appearing. And if library.a is an external dependency and hard to rebuild it's also not the first thing to try.