the shared-library search path
When your program needs libutil.so at run time, the dynamic linker has to actually locate that file somewhere on disk. The shared-library search path is the ordered list of directories it looks through to find it — like a librarian who checks a fixed set of shelves, in order, until the book turns up. If the library is on none of those shelves, the program fails to start.
On Linux the dynamic linker consults a few sources in order: any directories baked into the executable itself (the rpath/runpath), then the directories named in the LD_LIBRARY_PATH environment variable, then a cached list of standard system directories (built from /etc/ld.so.conf by ldconfig, covering places like /usr/lib and /lib). Windows and macOS have their own search rules, but the idea is the same: a defined order of places to look. Notice this is separate from the build-time library path (the -L flag): -L tells the linker where to find the library while building, but does nothing to help the program find it later when it runs.
Why it matters: a huge fraction of 'it worked on my machine but not yours' library problems are really search-path problems — the library exists, just not on a shelf the linker checks. Knowing the order lets you fix it deliberately: install the library to a standard directory and run ldconfig, set LD_LIBRARY_PATH for a quick test, or bake an rpath into the binary. LD_LIBRARY_PATH in particular is handy for experiments but a poor permanent solution, and overriding it carelessly can even be a security risk.
Program cannot find its library at run time: $ ./app error: libutil.so: cannot open shared object file Quick fix for a test: $ LD_LIBRARY_PATH=. ./app # also look in the current directory
The search path decides where the dynamic linker looks; setting LD_LIBRARY_PATH adds a directory to that list.
The run-time search path is not the same as the build-time -L library path: -L only helps the linker during building, while the run-time search path (rpath, LD_LIBRARY_PATH, the ldconfig cache) is what the program uses to find the library when it actually runs.