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.