What You Will Learn

• Why every C or C++ program on Linux links against libc automatically
• The difference between static and dynamic linking at the object-file level
• How to build and inspect a static library with a cross toolchain
• How to build and inspect a position-independent shared library
• How to read readelf output to see exactly what a binary depends on
• When to choose static linking for an embedded target, and when to avoid it

Prerequisites

• A working cross toolchain on your PATH (see Lecture 8, “Using Your New Cross Toolchain”)
• Basic familiarity with compiling a single C file with gcc
• A Linux host — any recent distribution is fine

Every Program Links Against libc — Whether You Ask or Not

On Linux, the C library (glibc, musl, or uClibc-ng depending on how you configured your toolchain) is so fundamental that your cross compiler pulls it in automatically. You never have to write -lc on the command line. Every other library, though — libm for math functions, libpthread-style threading symbols in modern glibc, a vendor SDK, or your own code split into a reusable component — has to be named explicitly with the -l flag, where the library name has its lib prefix and file extension stripped off.

Two completely different mechanisms can satisfy that -l request, and the toolchain does not care which one you pick unless you tell it to. That choice is the core of this lecture.

Static Linking: Copy the Code In

With static linking, the linker copies the actual machine code for every function your program calls — plus anything those functions themselves depend on — out of a library archive and welds it directly into your final executable. Once the build finishes, that executable is self-contained: it needs nothing else on the target’s filesystem to run those functions.

Static library archives use the extension .a and are built with the ar tool, not the linker directly. Say you have two small original source files that make up a tiny math helper library:

// ep_square.c
int ep_square(int x) {
    return x * x;
}

// ep_cube.c
int ep_cube(int x) {
    return x * x * x;
}

Turn them into object files, then archive them into a static library:

$ ${CROSS_COMPILE}gcc -c ep_square.c
$ ${CROSS_COMPILE}gcc -c ep_cube.c
$ ${CROSS_COMPILE}ar rc libep_mathutil.a ep_square.o ep_cube.o
$ ls -l
-rw-r--r-- 1 ravi ravi  912 Aug 12 09:10 ep_cube.o
-rw-r--r-- 1 ravi ravi  904 Aug 12 09:10 ep_square.o
-rw-r--r-- 1 ravi ravi 2208 Aug 12 09:10 libep_mathutil.a

Now write a tiny demo that calls both functions and link it statically against your new library:

// ep_democalc.c
#include <stdio.h>
int ep_square(int);
int ep_cube(int);

int main(void) {
    printf("square(5) = %d\n", ep_square(5));
    printf("cube(5)   = %d\n", ep_cube(5));
    return 0;
}

$ ${CROSS_COMPILE}gcc ep_democalc.c -L. -lep_mathutil -o ep_democalc
$ ${CROSS_COMPILE}gcc -static ep_democalc.c -L. -lep_mathutil -o ep_democalc-static

$ ls -l ep_democalc ep_democalc-static
-rwxr-xr-x 1 ravi ravi    9832 Aug 12 09:14 ep_democalc
-rwxr-xr-x 1 ravi ravi  712104 Aug 12 09:14 ep_democalc-static

Notice the size jump once -static forces even glibc itself to be pulled into the binary. Static linking is genuinely useful in a few specific embedded situations: an early-boot recovery tool that must run before the root filesystem with your runtime libraries is even mounted, a minimal BusyBox-only rescue image where you would rather avoid shipping the runtime linker at all, or a single-purpose appliance image where you are only ever going to use a handful of libc symbols and don’t want the overhead of the full shared library.

Dynamic Linking: Reference the Code, Resolve It at Runtime

Dynamic (shared) linking takes the opposite approach: your executable stores only a reference to the library and its symbols. The actual code stays in a separate .so file on the target, and a runtime linker locates and loads it the moment your program starts.

To build a shared library, the object code must be position-independent, because the runtime linker is free to place it anywhere in memory. That means compiling with -fPIC, then linking with -shared instead of archiving with ar:

$ ${CROSS_COMPILE}gcc -fPIC -c ep_square.c
$ ${CROSS_COMPILE}gcc -fPIC -c ep_cube.c
$ ${CROSS_COMPILE}gcc -shared -o libep_mathutil.so ep_square.o ep_cube.o

$ ${CROSS_COMPILE}gcc ep_democalc.c -L. -lep_mathutil -o ep_democalc_dyn

This time the -l flag resolves to the shared object, and instead of code being copied in, a dependency reference is recorded. You can prove it with readelf:

$ ${CROSS_COMPILE}readelf -a ep_democalc_dyn | grep "Shared library"
0x00000001 (NEEDED)   Shared library: [libep_mathutil.so]
0x00000001 (NEEDED)   Shared library: [libc.so.6]

$ ${CROSS_COMPILE}readelf -a ep_democalc_dyn | grep "program interpreter"
    [Requesting program interpreter: /lib/ld-linux-aarch64.so.1]

That “program interpreter” line is the runtime linker itself — it must exist on the target filesystem, and it is the piece of software that actually finds libep_mathutil.so at process start, using the default search paths /lib and /usr/lib, or any extra directories you list in the colon-separated LD_LIBRARY_PATH environment variable.

Comparing the Two Approaches

Common Mistakes and Troubleshooting

• Forgetting -fPIC: linking without it produces relocation errors when building the shared object on some architectures — always compile shared-library sources with -fPIC.
• Assuming -static links everything: some NSS-based glibc features (like certain hostname resolution paths) still need dynamic loading even in a “static” binary — check your libc’s release notes if you rely on those.
• Library not found at runtime: if ep_democalc_dyn fails with “cannot open shared object file,” your .so isn’t in a directory the runtime linker searches — set LD_LIBRARY_PATH or install it to /usr/lib on the target.
• Mixing architectures: a shared library built for the wrong target architecture will fail to load with a format error — always double check you’re using the matching ${CROSS_COMPILE} prefix.

Best Practices

• Default to dynamic linking for normal application images — it keeps your rootfs smaller across multiple binaries and simplifies security updates.
• Reach for static linking only for a specific, justified case: early-boot tools, rescue shells, or single-binary appliances.
• Performance: dynamic linking adds a small, usually negligible, startup cost from symbol resolution — profile before assuming it matters on your target.
• Security: shared libraries let you patch a vulnerability (e.g., in libc) once and have every process pick it up on next start, without rebuilding your whole image — a real advantage over static linking at scale.

Summary and Key Takeaways

• libc is always linked automatically; every other library needs an explicit -l flag.
• Static linking copies dependency code directly into your executable via a .a archive built with ar.
• Dynamic linking keeps code in a separate .so, resolved at runtime by a program interpreter shown in readelf -a output.
• -fPIC plus -shared builds a shared object; -static forces full static linking.
• Choose based on your target’s constraints — boot-time availability of a filesystem, image size budget, and how often you’ll need to patch dependencies.

Static and dynamic linking is one of those cross-toolchain fundamentals that quietly shapes every embedded Linux image you’ll ever build. Once you can read a readelf -a dependency list confidently, you’ll never be surprised by a missing shared library on target again — and you’re ready for the next piece of the puzzle: how Linux handles versioning when a shared library’s interface changes underneath your running programs.

FAQ: Static and Dynamic Linking