Menu
When loading programs into memory, what is the difference between load-time dynamic linking and run-time dynamic linking?
241
Run-time dynamic linking enables the process to continue running even if a DLL is not available. The process can then use an alternate method to accomplish its objective. For example, if a process is unable to locate one DLL, it can try to use another, or it can notify the user of an error.
Linking and loading are two instruments that play a pivotal role in program execution. Linking intends to generate an executable module of a program by combining the object codes generated by the assembler. A loader, on the other hand, loads these executable modules to the main memory for execution.
Dynamic loading is a mechanism by which a computer program can, at run time, load a library (or other binary) into memory, retrieve the addresses of functions and variables contained in the library, execute those functions or access those variables, and unload the library from memory.
Definition. Static linking is the process of copying all library modules used in the program into the final executable image. In contrast, dynamic linking is the process of loading the external shared libraries into the program and then binds those shared libraries dynamically to the program.
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.
166
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
