Rpath

In computing, rpath designates the run-time search path hard-coded in an executable file or library. Dynamic linking loaders use the rpath to find required libraries.
Specifically, it encodes a path to shared libraries into the header of an executable (or another shared library). This RPATH header value (so named in the Executable and Linkable Format header standards) may either override or supplement the system default dynamic linking search paths.
The rpath of an executable or shared library is an optional entry in the codice_1 section of the ELF executable or shared libraries, with the type codice_2, called the codice_2 attribute. It can be stored there at link time by the linker. Tools such as codice_4 and codice_5 can create or modify the entry later.
Use of the DT_RPATH entry by the dynamic linker.
The different dynamic linkers for ELF implement the use of the codice_2 attribute in different ways.
GNU ld.so.
The dynamic linker of the GNU C Library searches for shared libraries in the following locations in order:
Failing to find the shared library in all these locations will raise the "cannot open shared object file: No such file or directory" error.
Notes:
The role of GNU ld.
The GNU Linker (GNU ld) implements a feature which it calls "new-dtags", which can be used to insert an rpath that has lower precedence than the codice_9 environment variable.
If the new-dtags feature is enabled in the linker (codice_30), GNU codice_31, besides setting the codice_2 attribute, also sets the codice_8 attribute to the same string. At run time, if the dynamic linker finds a codice_8 attribute, it ignores the value of the codice_2 attribute, with the effect that codice_9 is checked first and the paths in the codice_8 attribute are only searched afterwards.
The ld dynamic linker does not search codice_8 locations for transitive dependencies, unlike codice_2. 
Instead of specifying the codice_40 to the linker, the environment variable codice_41 can be set to the same effect.
Solaris ld.so.
The dynamic linker of Solaris, specifically codice_42 of SunOS 5.8 and similar systems looks for libraries in the directories specified in the LD_LIBRARY_PATH variable before looking at the codice_2 attribute. Sun Microsystems was the first to introduce dynamic library loading. Sun later added the rpath option to ld and used it in essential libraries as an added security feature. GNU ld did the same to support Sun-style dynamic libraries.
Example.
$ cc -shared -Wl,-soname,termcap.so.4,-rpath,/lib/termcap.so.4 -o termcap.so.4
$ objdump -a -x termcap.so.4
 NEEDED libc.so.6
 SONAME termcap.so.4
 RPATH /lib/termcap.so.4
In this example, GNU or Sun ld (ld.so) will REFUSE to load termcap for a program needing it unless the file codice_44 is in codice_45 and named codice_46. is ignored. If codice_47 is removed to remediate, the shell dies (one cannot load an alternate codice_44 and a rescue disk is needed, but also if a new codice_46 has RPATH /lib, ld.so will refuse to use to load it unless it clobbered codice_47). But there's another issue: it isn't safe to copy over some libs in codice_19 as they are "in use," further restricting the would-be lib tester. Furthermore, vs. means programs needing basic codice_44 are denied because the library above deleted the ABI access to basic support.
$ cc -shared -Wl,-soname,libtermcap.so.2 -o libtermcap.so.2
$ objdump -a -x termcap.so.2
 NEEDED libc.so.6
 SONAME termcap.so.2
Old Linux/Sun used the above, which allows a user to direct any program to use any codice_44 they specify in , or what is found in /usr/local/lib(n) using the search rules such as codice_54. However, GNU ld always uses codice_19 or codice_20 regardless before , so first codice_57 is moved to codice_58 and that mentioned in codice_54, which enables use of moving codice_60 and codice_54 or use of to use. A preferred practice is to use "" and have programs check version (all libs do support that) to use features available, but that was often skipped in old releases due to slow computing speed and lack of time to code correctly.
That being said, test this kind of thing thoroughly on a given platform before deciding to rely on it. Release administrators today are not guaranteed to respect past guidelines or documentation. Some UNIX varieties link and load in a completely different way. rpath is specific to ld shipped with a particular distribution.
Lastly, as said, rpath is a security feature however "mandatory access control" (MAC) and other techniques can be as effective or more effective than rpath to control lib reading and writing.
Control over rpath using today's compilers is often nearly impossible given lengthy and convoluted make(1) scripting. Worse, some build scripts ignore --disable-rpath even though they present it as an option. It would be time-consuming and frustrating, and probably unfeasible, to fix build scripting in every odd program to compile.
A simple sh(1) "wrapper" can call the real ld, named ld.bin. The wrapper can filter in/out option before invoking ld.
 #!/bin/sh
 # - filter ld options here -
 ld.bin $opts
However, note that some builds incorrectly use rpath instead of rpath-link or or to locate intermediate products that stay in the build directory - thus backwardly demand rpath in the final product, which is a new issue concerning "what is rpath".