102.3 Manage shared libraries

Introduction

This lesson is about shared libraries.

The main question is:

How does a program find the code it depends on when that code is not inside the program file itself?

What you should be able to do after this lesson:

• Explain what a shared library is.
• Use ldd to inspect dependencies.
• Know common library locations.
• Understand what ldconfig, ld.so.conf, and LD_LIBRARY_PATH do.
• Follow a simple troubleshooting flow when a library cannot be found.

Big Idea: The Program Is Small, the Libraries Are Shared

Many Linux programs do not contain all of their code inside one big executable file.

Instead:

1. the executable says which shared libraries it needs
2. the dynamic linker looks for those libraries
3. if the right libraries are found, the program starts
4. if not, the program fails before normal work even begins

That is the whole beginner picture.

A shared library is useful because:

• many programs can reuse the same code
• package updates can replace one library for many programs
• executables stay smaller

But there is a tradeoff:

• the program now depends on the system finding the right library at runtime

Everyday Picture

Think of it like this:

executable file -> dynamic linker -> library search -> program starts

If the search succeeds, the program runs. If the search fails, you get a "cannot open shared object file" style error.

That is why library problems often look mysterious at first. The executable exists, but one of its dependencies is missing or invisible.

See What a Program Needs

The classic tool is:

ldd /bin/ls

Typical output looks like:

linux-vdso.so.1 (0x...)
libcap.so.2 => /usr/lib/libcap.so.2 (0x...)
libc.so.6 => /usr/lib/libc.so.6 (0x...)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x...)

How to read it:

• left side = library name
• right side = where the library was found
• hexadecimal addresses = runtime details you do not need first

What this tells you:

• one program can depend on several libraries
• the important question is not only "what library?"
• it is also "where was it found?"

Where the System Looks for Libraries

At beginner level, the important places are:

• standard library directories such as /lib and /usr/lib
• extra directories configured in ld.so config files
• the linker cache
• temporary paths from LD_LIBRARY_PATH

You do not need to memorize the exact search order for LPIC-1. You do need a clear map of the moving parts.

Common Library Locations

Typical places include:

• /lib
• /lib64
• /usr/lib
• /usr/lib64

Exact paths vary by distribution and architecture.

Simple rule:

• if a library is in a standard location, the system often finds it easily
• if it is in a custom location, you may need extra configuration

What ldconfig Does

ldconfig updates the shared library cache and links.

Simple idea:

after new libraries are installed in standard library paths, ldconfig helps the system find them efficiently

Common command:

sudo ldconfig

See the linker cache

You may also see:

ldconfig -p | head

Why this matters:

• it shows libraries known to the linker cache
• it helps confirm whether a library is already visible to the system

/etc/ld.so.conf and /etc/ld.so.conf.d/

These files tell the dynamic linker about extra library search paths.

Common names to recognize:

/etc/ld.so.conf
/etc/ld.so.conf.d/
/etc/ld.so.cache

Simple workflow:

1. add or confirm a library path
2. run ldconfig
3. test the program again

This is one of the most common admin patterns around shared libraries.

LD_LIBRARY_PATH

This environment variable adds library search paths for a program.

Example:

export LD_LIBRARY_PATH=/opt/myapp/lib

This can be useful for testing, but beginners should be careful:

• it changes library search behavior
• it can hide a packaging or installation problem
• it affects only processes started from that shell environment

For production systems, proper package-based installation is usually cleaner.

Common Failure Patterns

When library loading breaks, the problem is often one of these:

• the required library file is missing
• the file exists, but not in a searched location
• the cache was not updated after installation
• the program expects a different library version or SONAME
• LD_LIBRARY_PATH points the program at an unexpected place

That is enough detail for a strong beginner mental model.

A Simple Troubleshooting Flow

If a program says a library is missing:

1. Read the error carefully.
2. Run ldd <program>.
3. Check whether the missing library appears at all.
4. Check standard library directories and ld.so config files.
5. If a new library was installed into a standard path, run sudo ldconfig.
6. Use LD_LIBRARY_PATH only when you understand why you need it.

Practice Step by Step

1) Check what `/bin/ls` depends on

1. Run: ldd /bin/ls
2. Look at the library names on the left.
3. Look at the resolved paths on the right.
4. Notice that one executable depends on several shared libraries.

2) Inspect the linker cache

1. Run: ldconfig -p | head
2. Read it as: libraries already known to the system cache.
3. Notice that this is useful when you need to confirm visibility, not just file existence.

3) Think through a missing-library error

1. Imagine a program says: error while loading shared libraries: libexample.so: cannot open shared object file
2. Your first checks should be: ldd <program> cat /etc/ld.so.conf
3. If a new library was installed into a standard path, run: sudo ldconfig
4. Test the program again.

Cheat Sheet

• shared library = code reused by many programs
• dynamic linker = component that finds needed shared libraries at program start
• ldd = show library dependencies
• common library paths = /lib, /usr/lib, and architecture variants
• ldconfig = update linker cache and links
• /etc/ld.so.conf = extra library search path config
• /etc/ld.so.cache = linker cache file
• LD_LIBRARY_PATH = temporary extra library search path