What is the linker and what is the loader in dynamic linking?

Computer Systems: A Programmer's Perspective (3ed) says on p733 that > **7.9 Loading Executable Object Files** > > To run an executable object file prog, we can type its name to the Linux shell’s command line: > > linux> ./prog > > Since prog does not correspond to a built-in shell command, the shell assumes that prog is an executable object file, which it runs for us by invoking some memory-resident operating system code known as **the loader**. Any Linux program can invoke the loader by calling the execve function, which we will describe in detail in Section 8.4.6 and in p736: during dynamic linking > **7.10 Dynamic Linking with Shared Libraries** > > Once we have created the library, we would then link it into our example program in Figure 7.7: > > linux> gcc -o prog2l main2.c ./libvector.so > > This creates an executable object file prog2l in a form that can be linked with libvector.so at run time. The basic idea is to do some of the linking statically when the executable file is created, and then complete the linking process dynamically when the program is loaded. It is important to realize that **none of the code or data sections from libvector.so are actually copied into the executable prog2l** at this point. Instead, **the linker copies some relocation and symbol table information** that will allow references to code and data in libvector.so to be resolved at load time. > > When the loader loads and runs the executable prog2l, it loads the partially linked executable prog2l, using the techniques discussed in Section 7.9. Next, it notices that prog2l contains a .interp section, which contains the path name of the dynamic linker, which is itself a shared object (e.g., ld-linux.so on Linux systems). Instead of passing control to the application, as it would normally do, the loader loads and runs the dynamic linker. > **The dynamic linker** then finishes **the linking task** by performing the following relocations: > - Relocating the text and data of libc.so into some memory segment > - Relocating the text and data of libvector.so into another memory segment > - Relocating any references in prog2l to symbols defined by libc.so and libvector.so The above dynamic linking case is the "static loading, dynamic linking" case in Stephen Kitt's reply : > static loading, dynamic linking: **the linker** is /usr/bin/ld again, but with shared libraries (.so); **the loader** is the binary’s interpreter, e.g. /lib64/ld-linux-x86-64.so.2 (which maps to /lib/x86_64-linux-gnu/ld-2.24.so currently) on Debian 9 on 64-bit x86, itself loaded by the kernel, which also loads the main executable; The difference is that CSAPP seems to say that the loader is (the kernel code behind) execve() and the linker is ld-linux.so (no linking happens at compile time by ld, and actual linking happens at load time by ld-linux.so). What is the linker and what is the loader in dynamic linking? Thanks.