Manage Shared Libraries

In this lesson, we explore how to manage shared libraries on Linux. You’ll learn about compilation vs. linking, static and dynamic libraries, naming conventions, library paths, dynamic linker configuration, and dependency inspection.

1. Compilation vs. Linking

Building an executable from source involves two key steps:

1. Compilation
   The compiler (e.g., gcc) translates source files (.c, .cpp) into object files (.o).

2. Linking
   The linker combines object files and connects them to libraries, producing the final executable.

Linking can be:

• Static: Library code is embedded into the executable.
• Dynamic: Executable references shared libraries at runtime.

2. Static Libraries vs. Shared Libraries

Static Libraries (.a)

• Merged into the executable at link time.
• No runtime dependency on external files.
• Larger binary size, but fully self-contained.

Shared (Dynamic) Libraries (.so)

• Executable holds references, not library code.
• Resolved by the dynamic linker at runtime.
• Multiple programs can share a single library instance in memory, saving disk and RAM.

3. Shared Library Naming Conventions

Shared libraries follow the SONAME pattern:

lib{name}.so.{major}

• lib: prefix
• .so: shared object
• {major}: major version

Example:

libpthread.so.0

On Debian 9.9, the GNU C library’s SONAME is libc.so.6, typically a symlink to the full version. Static archives end with .a, for example libpthread.a.

4. Common Library Locations

Shared libraries are usually installed in these directories:

5. Dynamic Linker Configuration

The dynamic linker (ld.so or ld-linux.so) reads /etc/ld.so.conf to locate libraries:

include /etc/ld.so.conf.d/*.conf

Each file in /etc/ld.so.conf.d/ lists absolute library directories, for example:

/usr/local/lib

After editing, rebuild the cache and create necessary symlinks:

sudo ldconfig -v

Sample output:

/usr/local/lib:
/lib/x86_64-linux-gnu:
    libfuse.so.2 -> libfuse.so.2.9.7
    libnss_myhostname.so.2 -> libnss_myhostname.so.2
    libidn.so.11 -> libidn.so.11.6.16
    ...

Query for a specific library:

sudo ldconfig -p | grep libfuse
# libfuse.so.2 (libc6,x86-64) => /lib/x86_64-linux-gnu/libfuse.so.2

Inspect the symlink:

ls -l /lib/x86_64-linux-gnu/libfuse.so.2
# lrwxrwxrwx 1 root root 16 Aug 21 2018 /lib/x86_64-linux-gnu/libfuse.so.2 -> libfuse.so.2.9.7

6. LD_LIBRARY_PATH Environment Variable

LD_LIBRARY_PATH is a colon-separated list of directories the dynamic linker checks before standard paths.

export LD_LIBRARY_PATH=/usr/local/mylib:$LD_LIBRARY_PATH
echo $LD_LIBRARY_PATH
# /usr/local/mylib:...

To remove it:

unset LD_LIBRARY_PATH

For permanent updates, add the export line to ~/.bashrc or /etc/profile.

7. Inspecting Dependencies with ldd

Use ldd to list shared libraries an executable depends on:

ldd /usr/bin/git

Example output:

linux-vdso.so.1 =>  (0x00007ffcbb310000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f18241eb000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1823fd1000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f1823db6000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1823b99000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f1823991000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f18235c7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f182445b000)

To list unused direct dependencies:

ldd -u /usr/bin/git

Example:

Unused direct dependencies:
    /lib/x86_64-linux-gnu/libz.so.1
    /lib/x86_64-linux-gnu/libpthread.so.0
    /lib/x86_64-linux-gnu/librt.so.1

Unused entries often result from linker options during the build process.

References

• GNU ldconfig Manual
• Linux Shared Libraries HOWTO
• ld.so.conf Configuration