Shared Libraries

Most programs on Linux don't contain all their own code. They're dynamically linked: at the moment you run them, the operating system finds and loads separate files called shared libraries (ending in .so, for "shared object") that contain code the program needs but didn't want to duplicate.

Analogy: Instead of every cookbook reprinting the full instructions for "how to boil water," every cookbook just says "see the shared Boiling Water reference." One copy of that reference (one .so file) serves every cookbook (every program) that needs it - saving disk space and letting you fix a bug in one place instead of every program that uses it.

Command	Purpose
`ldd /path/to/binary`	List libraries a binary needs
`ldconfig`	Rebuild the linker cache after adding libs
`LD_LIBRARY_PATH`	Env var adding extra library search dirs

For this to work at run time, the system needs a fast way to answer "where is libc.so.6 on disk?" without searching the entire filesystem every time a program starts. The dynamic linker solves this by reading a list of trusted directories from /etc/ld.so.conf (plus /etc/ld.so.conf.d/) and pre-building an index of every library it finds there, cached in /etc/ld.so.cache.

$ ldd /bin/ls
        linux-vdso.so.1
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6

This output tells you exactly which shared libraries /bin/ls will load, and where each one currently resolves to on disk - useful when two versions of a library exist and you need to know which one actually gets picked up.

Warning: The message error while loading shared libraries: libfoo.so: cannot open shared object file almost always means a .so file exists somewhere on disk but isn't in a directory the linker knows to search. The fix is to add that directory to a file in /etc/ld.so.conf.d/ and then run ldconfig to rebuild the cache - simply having the file present isn't enough; the cache has to be told about it.