Symbol Resolution Order

The dynamic loader builds an ordered list of objects and resolves every symbol by scanning it front to back. The order is: the executable itself, then anything named in LD_PRELOAD, then the executable's needed libraries in breadth-first order of the dependency graph, then anything loaded later with dlopen.

The consequence is global and often surprising: the first object defining malloc supplies malloc to *every* object in the process, including libraries that were built and tested against a different one. Resolution is not per-caller and not per-library — it is per-process, decided once, by position.

Note that the executable comes first. A program that defines its own malloc gets its own, and so does every library it loaded, whether they expected that or not. This is how allocator replacement works — link jemalloc into the executable and the whole process uses it — and it is also how a program can accidentally break a library by defining a common name at global scope.

Before it can resolve symbols, the loader must find the files. That search has its own order, and the order matters because it decides which copy of a library a program gets.

On glibc the sequence is: DT_RPATH recorded in the binary (deprecated, and notably it takes precedence over LD_LIBRARY_PATH), then LD_LIBRARY_PATH from the environment, then DT_RUNPATH recorded in the binary (which is checked *after* the environment variable, which is the whole reason it replaced RPATH), then the cache in /etc/ld.so.cache, then the default system directories.

The RPATH-versus-RUNPATH distinction is the practically important one. RPATH outranks the environment, so a binary with an RPATH cannot be redirected by LD_LIBRARY_PATH — which is either a security property or an operational obstruction depending on who you ask. RUNPATH is consulted after the environment, so it acts as a default that can be overridden. Modern linkers emit RUNPATH by default and --disable-new-dtags restores the old behavior.

Both support $ORIGIN, which expands to the directory containing the object. -Wl,-rpath,'$ORIGIN/../lib' is the standard way to ship an application with its own libraries in a relocatable directory tree, and it is what almost every bundled desktop application does.

Because the scope is scanned front to back and LD_PRELOAD inserts near the front, you can replace any function in any library without recompiling anything. This is a legitimately excellent technique. Memory debuggers replace malloc and free. Profilers wrap pthread_create. faketime replaces gettimeofday. Sanitizer runtimes, ltrace, and countless one-off debugging shims all work this way.

It is also, viewed from a different angle, arbitrary code execution in someone else's process controlled by an environment variable. If an attacker can set the environment of a process they cannot otherwise control — through a service manager's configuration, a CGI environment, a container spec, a sudo rule that preserves the environment — they can inject a library that runs their code in that process. The loader ignores LD_PRELOAD and LD_LIBRARY_PATH for set-user-ID binaries for exactly this reason, and that mitigation is narrow: it protects privilege *transitions*, not processes that are simply more privileged than the attacker's shell.

The same reasoning applies to search paths. A writable directory early in a program's RUNPATH, or a relative path in it, is a place an attacker can put a library that will be loaded in preference to the real one. This is a routine finding in security reviews of packaged applications, and it is the native-code analogue of a dependency-confusion attack: the resolution mechanism prefers something an attacker controls over the thing you meant.

The general defensive posture: do not put writable or relative directories on any search path, prefer RUNPATH with $ORIGIN over ambient environment variables, use full RELRO so the GOT cannot be rewritten after load, and on platforms that offer it prefer a two-level namespace so that a matching name in the wrong library is not a match at all.

The failure mode that is not an attack is more common and harder to spot. Two unrelated libraries define a symbol with the same name — init, parse, log_message, hash are all real examples — and the flat namespace resolves both to whichever came first. One library then calls the other's function, with the other's expectations about arguments and state.

The symptom is a crash or a wrong result inside a library that has nothing wrong with it, appearing only when a particular combination of dependencies is loaded, and often only in a particular order. Add an unrelated dependency and the problem appears or disappears. This is genuinely one of the hardest bug classes in native software, and the tell is that LD_DEBUG=bindings shows a symbol binding to an object nobody expected.

The fixes are all about not participating in the shared namespace. Hidden visibility keeps internal symbols out of the dynamic table entirely, which is the single most effective measure — see [[shared-libraries]]. -Bsymbolic or -Bsymbolic-functions makes a library bind its own references to its own definitions at link time, so it cannot be interposed against itself. A version script exports only what is intended. And prefixing public symbols with a library-specific prefix is the C answer to namespaces, unglamorous and effective.