what is the difference between linking and loading in c language

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

Both dynamic linking and library loading happen at run time, but dynamic linking is done prior to program execution and is done by system linker. So for example, if required libraries are missing, program cannot be executed. Library loading, on the other hand, is done by program itself, via dlopen/LoadLibrary functions. In this case, loading process is controlled by application, which can, for example handle errors.

Answer 6

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 :-)).

Answer 7

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 operation 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, 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:

• library updates after the application is released, which change the location of functions and data.
• single application running on different versions of the OS
• uncertainty about where the library or application may be loaded in memory
• reduce the size of the core by sharing physical ram used by libraries between multiple applications.

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 OS 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).