Why are static and dynamic linkable libraries different?

Question

If both of them contain compiled code, why can't we load the "static" files at runtime and why can't we link with the dynamic libraries at compile time? Why is there a need for separate formats to contain "standalone" code? What needs to be stored in either one that warrants the difference?

Answer 1

Static libraries are true libraries in the sense that they contain a library of object files. Each object file is often created from a single source file and contains machine code as well as information about data required for the code. During the link step the linker will pick the necessary object files and combine them into an executable.

One important part of machine code is that jumps, calls and data pointers will have to contain real memory addresses. However, if an object file needs to call another function in another object file it can only refer to that function using a symbol. When the linker combines the object files into executable code the symbol references are resolved and turned into real memory addresses.

A dynamic library is executable code that can be loaded into the memory and executed straight away. On some operating systems there may be an additional step where the code is rebased by moving the executable code to another location and this requires all absolute addresses within the code to be shifted by a fixed amount. This operation is still much faster than combining object files and resolving symbols done by the linker.

To sum it up:

• Static libraries contain pieces of executable code that uses symbols to refer to other pieces of executable code
• Dynamic libraries (and executables) contain executable code now placed at fixed locations enabling the symbols to be replaced with real memory addresses

If you've ever tried to link a reasonably sized project you will have noticed that it takes a non-trivial amount of time, probably longer than you would like to wait to start an application. That sort of explains why you can't execute static libraries. And dynamic libraries have been optimized and stripped to not contain anything except executable code which makes them unsuitable for use as static libraries.

Answer 2

The code in an object file isn't linked. It contains implicit references to external functions that have not yet been resolved.

When object files are linked to create a DLL, the linker looks through all those external references and finds other libraries (static or dynamic) that can satisfy them. A reference to a name in a static library is resolved by including the body of that function (or whatever) into the DLL. If it refers to a dynamic library, the name of both the DLL and the referenced function are included in the DLL.

Ultimately, there's no reason this would have to be the case. In theory, you could write the loader to do all of this every time you loaded a file. It's basically just an optimization: the linker does the relatively slow parts of the job. References to DLLs are left, but they're resolved to the point that it's fairly fast for the loader to find and load the target file (if necessary) and resolve the referenced functions. When the linker is doing its job, it does a lot more by scanning through long lists of definitions to find the ones you care about, which is quite a bit slower.