Does linking and loading of the the dynamic libraries both happen at runtime? or is it that only loading of the library happens at run time?
See the earlier very good point about the distinction between static linking and dynamic linking. Assuming you are referring to the dynamic linking, then:
Both loading and (dynamic) linking are done by the linker – on linux and other Unix-alikes this is done by /lib/ld.so
, which is the actual program that is launched by the operating system in almost all cases. ld.so
in turn loads your application - mygameBinary
into memory, and ld.so
then reads from the file mygameBinary
the list of dynamic linked libraries that it requires.
The linker, ld.so
, then loads each of these libraries into memory in turn, e.g. libc.so
, libpthread.so
, libopengl.so
, and looks at what other libraries these might require, e.g. libm.so
.
Once loading is done, then linking begins, a process of looking at named objects or functions which are exported by one library or the application, and imported by another library or application. The linker then changes various references and sometimes code to update unlinked data pointers and function calls in each library to point where the actual data or function resides. For example, a call to printf
in mygameBinary
starts off pointing at nothing (actually it just calls the linker), but after linking becomes a jump to the printf
function in libc
.
Once this linking is complete, the application is started, by invoking the _start
function in mygameBinary
, which then calls main
, and your game starts.
Dynamic linking in this way is necessary to support the following:
Some OSs differ in the details, for instance OSX and AIX both pre-load a certain set of libraries into fixed locations in memory. This means they don't need to be loaded, just linked, which may be faster.
Some OSs such as OSX and sometimes Linux support pre-linking, which is a process where a script runs over the applications on your system before you launch them, and does the linking. When you launch them, you then don't need to link them. This is important because linking takes a considerable amount of your computer's time when you launch an app, and some apps may be launched multiple times a second, such as gcc
, cpp
and as
during application build process, or filter scripts when indexing your computer's data (OSX Spotlight).
There are two types of linking: static linking and dynamic linking.
Static linking occurs at compilation time, hence it occurs prior to loading a program. With static linking the external symbols that are used by your program (e.g. function names) are resolved at compile time.
Dynamic linking occurs at run time, so it occurs after or at the time of the loading of a program. With dynamic linking the symbols are resolved either at loading time, or at run time when the symbol is accessed (lazy binding). The latter is more common.
Both happen at runtime for dynamic libraries.
First, the libraries are loaded, along with all their dependencies (and those libraries' dependencies, and so on). Then the dynamic linker resolves symbols in the loaded libraries. Usually both of these functions are implemented by the same piece of software; on Linux it's ld.so.
Symbols in static libraries are resolved at link time and included in the executable file itself. Static libraries may, however, have unresolved symbols that are satisfied at runtime by dynamic libraries.
There's an in-depth description of how this happens, how names are hashed, how expensive it is to resolve symbols at runtime, etc. in How to Write Shared Libraries.
file01.c, file02.c --> produces --> file01.o, file02.o --> These .o informations are clubbed and put into a single dynamic library, that is lib1.a file11.c, file12.c --> produces --> file11.o, file12.o --> These .o informations are clubbed and put into a single dynamic library, that is lib2.a
Now, I have 2 libraries that is finally linked together to generate the executable (like .elf or .mot or .fls). This process of linking information from lib1.a and lib2.a to form a single executable is called linking.
Now, I need to load this into memory in order to run it to see the behaviour of the final executable. The process of loading the final executable (like .elf or .mot or .fls) into memory in order to run that is called loading.
I hope this would clear the importance of linking and loading (however the definitions are not appropriate :-)).
Linking is the process of taking some smaller executables and joining them together as a single larger executable.
Loading is loading the executable into memory prior to execution.
Windows and Unix systems use completely different approaches to Dynamic libraries.
Windows DLLs are not linked. Therefore, you cannot share static objects across DLLs. It's just like a separate program in your address space.
Unix shared objects are really "linked" in run time, just as different modules of the same project, performing symbol resolution.