Unlike static libraries (where all object code is copied into the executable), shared libraries leave the code in a separate .so file. Two things must happen before your program can run:

• Embed the library name at link time: When you compile and link your program with gcc -o prog prog.c libfoo.so, the linker records the library’s name inside the ELF executable as a DT_NEEDED tag. This is called the program’s dynamic dependency list.
• Resolve & load the library at run time: The dynamic linker (/lib/ld-linux.so.2) reads the DT_NEEDED list, locates the .so file on disk, and maps it into the process’s address space before main() is called.

ELF Binary — Where the dependency is stored:

Let’s create a simple shared library with two modules and link a program against it.

Step 1: Write source files

/* mod1.c */
#include <stdio.h>

void mod1_func(void) {
    printf("Called mod1-x1\n");
}

/* mod2.c */
#include <stdio.h>

void mod2_func(void) {
    printf("Called mod2-x2\n");
}

/* prog.c */
void mod1_func(void);
void mod2_func(void);

int main(void) {
    mod1_func();
    mod2_func();
    return 0;
}

Step 2: Compile object files with Position Independent Code (-fPIC)

# -fPIC = Position Independent Code, required for shared libraries
# Code can be loaded at any address in memory
$ gcc -g -c -fPIC -Wall mod1.c mod2.c

Step 3: Create the shared library

# -shared  = create a shared library (not an executable)
# -o libfoo.so = output file name (must start with "lib", end with ".so")
$ gcc -g -shared -o libfoo.so mod1.o mod2.o

Step 4: Link the program against the shared library

# -L. = tell the linker to also look in current directory for libraries
# -lfoo = link with libfoo.so (linker strips "lib" prefix and ".so" suffix)
$ gcc -g -Wall -o prog prog.c -L. -lfoo

# OR directly name the .so file:
$ gcc -g -Wall -o prog prog.c libfoo.so

Step 5: Inspect embedded library name (DT_NEEDED)

# Use readelf to see what shared libraries the executable needs
$ readelf -d prog | grep NEEDED
 0x00000001 (NEEDED)  Shared library: [libfoo.so]
 0x00000001 (NEEDED)  Shared library: [libc.so.6]

# Alternatively with objdump:
$ objdump -p prog | grep NEEDED
  NEEDED               libfoo.so
  NEEDED               libc.so.6

Step 6: Try to run — and see the error

$ ./prog
./prog: error in loading shared libraries: libfoo.so: cannot open
shared object file: No such file or directory

The dynamic linker is itself a shared library named /lib/ld-linux.so.2. It is automatically invoked by the Linux kernel every time an ELF executable that uses shared libraries is started.

Runtime loading flow:

Check which dynamic linker an executable uses:

# See PT_INTERP — the dynamic linker path
$ readelf -l prog | grep interpreter
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

# On 32-bit x86:
#   /lib/ld-linux.so.2

# On x86-64 (64-bit):
#   /lib64/ld-linux-x86-64.so.2

# On ARM:
#   /lib/ld-linux-armhf.so.3  (or similar)

# On IA-64:
#   /lib/ld-linux-ia64.so.2

Verify standard library search paths of the dynamic linker:

# /etc/ld.so.conf lists extra directories searched by the dynamic linker
$ cat /etc/ld.so.conf

# ldconfig regenerates the cache /etc/ld.so.cache from the config
$ sudo ldconfig

# Print standard library paths and cache contents
$ ldconfig -v 2>/dev/null | head -20

# See all libraries in the cache
$ ldconfig -p | head -20

Check which libraries a binary needs at runtime:

# ldd traces which shared libraries an executable depends on
$ ldd prog
    linux-vdso.so.1 (0x00007ffd5c5f9000)
    libfoo.so => not found              ← our library is missing!
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f...)
    /lib64/ld-linux-x86-64.so.2 (0x00007f...)

# Once LD_LIBRARY_PATH is set, ldd shows it found:
$ LD_LIBRARY_PATH=. ldd prog
    ...
    libfoo.so => ./libfoo.so (0x00007f...)
    ...

LD_LIBRARY_PATH is a colon-separated list of directories that the dynamic linker will search before the standard directories. It is the quickest way to run a program that uses a shared library stored in a non-standard location (e.g., current directory, custom build folder).

Basic usage — run program with library in current directory:

# Tell dynamic linker to also search current directory (.)
$ LD_LIBRARY_PATH=. ./prog
Called mod1-x1
Called mod2-x2

# Multiple directories (colon-separated):
$ LD_LIBRARY_PATH=/home/ravi/libs:/tmp/test ./prog

# Prepend to existing value:
$ LD_LIBRARY_PATH=/my/lib:$LD_LIBRARY_PATH ./prog

# Export for all subsequent commands in the shell session:
$ export LD_LIBRARY_PATH=/home/ravi/libs
$ ./prog

Dynamic linker search order:

The proper production way to embed a library search path is to bake it directly into the ELF binary using -rpath. This way the binary always knows where to find its libraries without any environment variable.

# Embed /home/ravi/libs as RPATH inside the executable
$ gcc -g -Wall -o prog prog.c -L. -lfoo \
      -Wl,-rpath,/home/ravi/libs

# The binary will now always search /home/ravi/libs at runtime
$ ./prog          # works without LD_LIBRARY_PATH!

# Inspect the embedded RPATH:
$ readelf -d prog | grep -i rpath
 0x0000000f (RPATH)   Library rpath: [/home/ravi/libs]

# Use $ORIGIN to make RPATH relative to the executable's own directory:
# Very useful for distributable applications
$ gcc -g -Wall -o prog prog.c -L. -lfoo \
      '-Wl,-rpath,$ORIGIN'

# Now prog always looks for .so files in its own directory:
$ readelf -d prog | grep -i rpath
 0x0000000f (RPATH)   Library rpath: [$ORIGIN]

Every program goes through a static-linking phase (combining object files into an executable). Programs using shared libraries additionally undergo dynamic linking at runtime.

# ─── CREATE THE STATIC LIBRARY (archive) ───────────────────────
$ ar rcs libfoo_static.a mod1.o mod2.o
# ar = archive tool; rcs = replace, create, sort-index

# ─── LINK STATICALLY ────────────────────────────────────────────
# All code from libfoo_static.a is COPIED into prog_static
$ gcc -g -Wall -static -o prog_static prog.c -L. -lfoo_static
# OR:
$ gcc -g -Wall -o prog_static prog.c libfoo_static.a

# ─── LINK DYNAMICALLY ───────────────────────────────────────────
# prog_dynamic only REFERENCES libfoo.so — code stays in the .so
$ gcc -g -Wall -o prog_dynamic prog.c -L. -lfoo

# ─── COMPARE SIZES ──────────────────────────────────────────────
$ ls -lh prog_static prog_dynamic
-rwxr-xr-x 1 ravi ravi 820K  prog_static   ← BIG (all of libc included!)
-rwxr-xr-x 1 ravi ravi  16K  prog_dynamic  ← small (just references)

# ─── ldd COMPARISON ─────────────────────────────────────────────
$ ldd prog_static
    not a dynamic executable      ← no shared lib dependencies!

$ ldd prog_dynamic
    libfoo.so => ./libfoo.so (0x00007f...)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f...)
    /lib64/ld-linux-x86-64.so.2 (0x00007f...)

Key comparison table:

# ─── See shared libraries being loaded in real time (strace) ────
$ strace -e openat ./prog_dynamic 2>&1 | grep "\.so"
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libfoo.so", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
# You can see exactly which .so files are opened and when!

On architectures that support both 32-bit and 64-bit execution (like x86-64), the libraries are stored in separate directories to avoid conflicts:

# Check your system's lib directories
$ ldconfig -v 2>/dev/null | grep "^/"
/usr/lib/x86_64-linux-gnu:
/usr/lib:
/lib/x86_64-linux-gnu:
/lib:

# Install a shared library system-wide (add to /usr/local/lib and run ldconfig)
$ sudo cp libfoo.so /usr/local/lib/
$ sudo ldconfig        # updates /etc/ld.so.cache
$ ./prog               # now works without LD_LIBRARY_PATH!