Why Dynamic Linking Beats Static Linking: Benefits, Techniques, and Code Samples

Why use dynamic linking?

Static linking embeds a copy of each library in every executable, wasting disk space and RAM when many programs share the same code. Updating a statically linked program also requires rebuilding the whole binary. Dynamic linking stores a single copy of a shared object in memory and on disk, and resolves symbols at runtime, reducing memory usage and simplifying independent development.

Creating and using a shared library

Source for the library:

// lib.c
#include <stdio.h>

void func(int i) {
    printf("func %d 
", i);
}

Compile the library as position‑independent code: gcc -fPIC -shared -o lib.so lib.c Program that uses the library:

// program.c
void func(int i);

int main() {
    func(1);
    return 0;
}

Link the program with the shared object and run:

gcc -o test program.c ./lib.so
./test
# output: func 1

Inspect the shared object with readelf:

readelf -l lib.so
Elf file type is DYN (Shared object file)
Entry point 0x530
Program Headers:
  Type           Offset   VirtAddr           PhysAddr   FileSiz  MemSiz  Flags  Align
  LOAD           0x0      0x0                0x0        0x6e4    0x6e4   R E    0x200000
  ... (truncated)

Dynamic linking mechanisms

Load‑time relocation : Absolute addresses are not fixed at link time; the loader relocates them when the shared object is mapped into the process address space.

Position‑independent code (PIC) : The compiler generates code that accesses symbols through the Global Offset Table (GOT), a pointer array placed in the data segment. Each process gets its own GOT copy, allowing the code segment to be shared.

Lazy binding with PLT

At program start the dynamic linker loads required shared objects and performs symbol relocation, which can slow startup. Lazy binding defers the resolution of external function symbols until the first call. The ELF file contains a .plt section; each external function has an entry that initially jumps to the dynamic linker. On first use the real address is looked up, stored in the corresponding .got.plt entry, and subsequent calls jump directly to the function.

Explicit runtime linking (dlopen API)

Four core functions are provided for runtime loading:

dlopen()   // open a shared library
dlsym()    // look up a symbol
dlerror()  // retrieve error information
dlclose()  // close the library

Example code that loads lib.so at runtime:

#include <stdio.h>
#include <dlfcn.h>

int main() {
    void *handle = dlopen("./lib.so", RTLD_NOW);
    if (!handle) {
        printf("dlopen failed
");
        return 1;
    }
    void (*f)(int) = dlsym(handle, "func");
    char *err = dlerror();
    if (err) {
        printf("dlsym error: %s
", err);
        return 1;
    }
    f(100);
    dlclose(handle);
    return 0;
}

Compile and run:

gcc -o test program.c -ldl
./test
# output: func 100

Summary

Dynamic linking eliminates the memory and deployment drawbacks of static linking by sharing a single copy of libraries at runtime. It relies on load‑time relocation, position‑independent code with a GOT, optional lazy binding via the PLT, and the dlopen family for explicit runtime loading.

References: https://www.ibm.com/developerworks/cn/linux/l-dynlink/index.html http://chuquan.me/2018/06/03/linking-static-linking-dynamic-linking/ https://www.cnblogs.com/tracylee/archive/2012/10/15/2723816.html 《程序员的自我修养：链接装载与库》