Linux binaries require dynamic linking (linking at run time) unless the -static option was given to ld(1) during compilation.
The program ld.so handles a.out binaries, a format used long ago; ld-linux.so* handles ELF (/lib/ld-linux.so.1 for libc5, /lib/ld-linux.so.2 for glibc2), which everybody has been using for years now. Otherwise, both have the same behavior, and use the same support files and programs ldd(1), ldconfig(8), and /etc/ld.so.conf.
When resolving shared object dependencies, the dynamic linker first inspects each dependency string to see if it contains a slash (this can occur if a shared object pathname containing slashes was specified at link time). If a slash is found, then the dependency string is interpreted as a (relative or absolute) pathname, and the shared object is loaded using that pathname.
If a shared object dependency does not contain a slash, then it is searched for in the following order:
ld.so understands certain strings in an rpath specification (DT_RPATH or DT_RUNPATH); those strings are substituted as follows
so that it finds an associated shared object in somedir/lib no matter where somedir is located in the directory hierarchy. This facilitates the creation of "turn-key" applications that do not need to be installed into special directories, but can instead be unpacked into any directory and still find their own shared objects.
LD_ASSUME_KERNEL can be used to cause the dynamic linker to assume that it is running on a system with a different kernel ABI version. For example, the following command line causes the dynamic linker to assume it is running on Linux 2.2.5 when loading the shared objects required by myprog:
$ LD_ASSUME_KERNEL=2.2.5 ./myprog
On systems that provide multiple versions of a shared object (in different directories in the search path) that have different minimum kernel ABI version requirements, LD_ASSUME_KERNEL can be used to select the version of the object that is used (dependent on the directory search order). Historically, the most common use of the LD_ASSUME_KERNEL feature was to manually select the older LinuxThreads POSIX threads implementation on systems that provided both LinuxThreads and NPTL (which latter was typically the default on such systems); see pthreads(7).
Then there are lots of more or less obscure variables, many obsolete or only for internal use.
The dynamic linker will notify the audit shared objects at so-called auditing checkpoints---for example, loading a new shared object, resolving a symbol, or calling a symbol from another shared object---by calling an appropriate function within the audit shared object. For details, see rtld-audit(7). The auditing interface is largely compatible with that provided on Solaris, as described in its Linker and Libraries Guide, in the chapter Runtime Linker Auditing Interface.