Difference between load-time dynamic linking and run-time dynamic linking

Question

When loading programs into memory, what is the difference between load-time dynamic linking and run-time dynamic linking?

Answer 1

load-time linking is when symbols in the library, referenced by the executable (or another library) are handled when the executable/library is loaded into memory, by the operating system.

Run-time linking is when you use an API provided by the OS or through a library to load a DLL or DSO when you need it, and perform the symbol resolution then.

I know more about Linux DSOs than Windows DLL's but the principle should be the same. .NET libraries may differ.

In linux, plugin architectures are done this way. Your program will use runtime linking to load up a library and call some functions. Then maybe unload it. It also allows multiple libraries with the same symbols exported to be loaded without clashing. I think DLLs will work in much the same manner.

Executables have "blank spaces" in their symbol tables that need filling by some library. These blank-spaces are usually filled in at load-time, or compile time. You can negate the need for "blank spaces" in the symbol table by using runtime linking.

Another scenario where runtime linking is useful is for debugging libraries, or selecting from multiple, ABI/API compatible libraries at runtime. I often have a library, say "foo" and one called "foo_unstable" and have a test app that switches between the 2 and does some testing.

Under linux, to see what libraries an executable links to at load-time you run the ldd command and get output such as (on /bin/ls):

linux-vdso.so.1 =>  (0x00007fff139ff000)
librt.so.1 => /lib64/librt.so.1 (0x0000003c4f200000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003c4fa00000)
libcap.so.2 => /lib64/libcap.so.2 (0x0000003c53a00000)
libacl.so.1 => /lib64/libacl.so.1 (0x0000003c58e0000

The operating system will attempt to load the libraries (the .so files) at load-time. It may already have the library in memory.

Answer 2

Aiden Bell covered the fundamentals, but I'll add:

Load time dynamic linking is usually accomplished by statically linking your application to a .lib or .a file that contains the code for automatically establishing runtime links to symbols to be found in .dll or .so files at program startup. This is usually for fixed functionality (i.e. the C runtime library, etc.) and allows your program to reap the benefits of bug fixes in the libraries while keeping executable size small (by factoring common code into a single library).

Runtime linking is used for more dynamic functionality such as plugin loading. As Aiden said, you use LoadLibrary() or the equivalent to actively attach modules to your program at runtime, perhaps by interrogating a directory containing plugin DLLs, loading each one in turn and talking to it with a homegrown plugin API. By doing so, your program can load modules that did not even exist when your app was compiled/linked, and can thus grow organically after deployment.

Fundamentally both methods end up invoking the LoadLibrary() API, but using a fixed set of symbols and libraries in the former case and a more dynamic set in the latter.