rpath is a term in programming which refers to a run-time search path hard-coded in an executable file or library, used during dynamic linking to find the libraries the executable or library requires.

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 .dynamic section of the ELF executable or shared libraries, with the type DT_RPATH, called the DT_RPATH attribute. It can be stored there at link time by the linker. Tools such as chrpath and patchelf can create or modify the entry later.

Contents

1 Use of the DT_RPATH entry by the dynamic linker
2 GNU ld.so
2.1 The role of GNU ld
3 Solaris ld.so
4 example
5 Control over rpath using today's compilers
6 References
7 External links

Use of the DT_RPATH entry by the dynamic linker

The different dynamic linkers for ELF implement the use of the DT_RPATH attribute in different ways.
GNU ld.so

The dynamic linker of the GNU C Library and its derivative Embedded GLIBC implement a rather complicated algorithm for searching for shared libraries. The basic search order is:[1]

The (colon-separated) paths in the DT_RPATH dynamic section attribute of the binary if present and DT_RUNPATH attribute does not exist.
The (colon-separated) paths in the environment variable LD_LIBRARY_PATH, unless the executable is a setuid/setgid binary, in which case it is ignored. LD_LIBRARY_PATH can be overridden by calling the dynamic linker with the option --library-path (e.g. /lib/ld-linux.so.2 --library-path $HOME/mylibs myprogram).
The (colon-separated) paths in the DT_RUNPATH dynamic section attribute of the binary if present.
Lookup based on the ldconfig cache file (often located at /etc/ld.so.cache) which contains a compiled list of candidate libraries previously found in the augmented library path (set by /etc/ld.so.conf). If, however, the binary was linked with the -z nodeflib linker option, libraries in the default library paths are skipped.
In the trusted default path /lib, and then /usr/lib. If the binary was linked with the -z nodeflib linker option, this step is skipped.

Notes:

The option --inhibit-rpath LIST of the dynamic linker instructs it to ignore DT_RPATH and DT_RUNPATH attributes of the object names in LIST.
Libraries specified by the environment variable LD_PRELOAD and then those listed in /etc/ld.so.preload are loaded before the search begins. A preload can thus be used to replace some (or all) of the requested library's normal functionalities, or it can simply be used to supply a library that would otherwise not be found.
Static libraries are searched and linked into the ELF file at link time and are not linked at run time.

The role of GNU ld

The GNU Linker (GNU ld) implements a feature which it calls "new-dtags": [2]

If the new-dtags feature is enabled in the linker (at run time using --enable-new-dtags), GNU ld, besides setting the DT_RPATH attribute, also sets the DT_RUNPATH attribute to the same string. At run time, if the dynamic linker finds a DT_RUNPATH attribute, it ignores the value of the DT_RPATH attribute, with the effect that LD_LIBRARY_PATH is checked next and the paths in the DT_RUNPATH attribute are only searched after it.

This means that in such configurations, the paths in LD_LIBRARY_PATH are searched before those given at link time using -rpath if --enable-new-dtags was active.

The ld dynamic linker does not search DT_RUNPATH locations for transitive dependencies, unlike DT_RPATH. [3]

Instead of specifying the -rpath to the linker, the environment variable LD_RUN_PATH can be set to the same effect.
Solaris ld.so

The dynamic linker of Solaris, specifically /lib/ld.so of SunOS 5.8 and similar systems looks for libraries in the directories specified in the LD_LIBRARY_PATH variable before looking at the DT_RPATH attribute. Sun Micro was the first to introduce dynamic lib loading. Sun later added rpath option to ld and used it in essential libs as an added security feature. GNU ld did the same to support Sun style dynamic libs. Historically long before that, assembler (asm) programs loaded objects from disk directly into code segment memory an ran it (the asm code would use relative addresses if any, a loader was not needed).

that's just repeating a manpage better read using man(1). it's also wrong - it perverts what the manpages say.

would someone please say what rpath is ?

Solaris ld.so

The dynamic linker of Solaris, specifically /lib/ld.so of SunOS 5.8 and similar systems looks for libraries in the directories specified in the LD_LIBRARY_PATH variable before looking at the DT_RPATH attribute. Sun Micro was the first to introduce dynamic lib loading. Sun later added rpath option to ld and used it in essential libs as an added security feature. GNU ld did the same to support Sun style dynamic libs. Historically long before that, assembler (asm) programs loaded objects from disk directly into code segment memory an ran it (the asm code would use relative addresses if any, a loader was not needed).
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

Above: GNU or Sun ld (ld.so) will REFUSE to load termcap for a program needing unless file termcap.so is in /lib/ and named termcap.so.4. LD_LIBRARY_PATH is ignored. Unfortunately this prevents (testing) trying a newly compiled termcap.so as ld always looks in /lib and /usr/lib first, reguardless. If /lib/termcap.so.4 is removed to remediate: the shell dies (one cannot load and alternate termcap.so and a rescue disk is needed, but also if a new termcap.so.4 has RPATH /lib, ld.so will refuse to use to load it unless it clobbered /lib/termcap.so.4). But there's another issue: it isn't safe to copy over some libs in /lib as they are "in use": further restricting the would be lib tester. Furthermore, SONAME termcap.so.4 v. SONAME termcap.so means programs needing basic termcap.so 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 or sun used the above, which allows a user to direct any program to use any any termcap.so they specify in LD_LIBRARY_PATH or what is found in /usr/local/lib(n) using the search rules such as ld.so.conf However! GNU ld always uses /lib or /usr/lib reguardless obstinately before LD_LIBRARY_PATH, so first /lib/termcap.so is moved to /usr/local/lib and that mentioned in ld.so.conf, which enables use of moving libs and ld.so.conf or use of LD_LIBRARY_PATH to (choose library or groups of libraries) to use. A preffered practice is to use "SONAME termcap.so" 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, things change: test this kind of thing thoroughly on a given platform before deciding to rely on it. Release administrators today are not respecting any guidelines or documentation of the past. Some unix do linking and loading 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 the same as an option. It would be impossible, timely and frustrating, to invite fixing 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 -rpath option before invoking ld.

#!/bin/sh
# - filter ld options here -
ld.bin $opts

But note some builds incorrectly use rpath instead of rpath-link or LD_LIBRARY_PATH or $(TOP)/dir/foo.so 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".

your pulling old foomanchews leg. the manpages dont say that - well they dont not say that either, but

rpath falls into a category of assembler level options that can be used to craft cascade failure of a unix line of products - generations of products with it

that can't be true. why then would so many people adding WIN32 support to linux be using rpath religiously and in new ways?

google

New Efficient Attacks on Statistical Disclosure Control Mechanisms
research.microsoft.com/pubs/64341. attack, requiring only a fixed number of queries for each bit revealed. 1 Introduction. The goal of a statistical database is to provide statistics about a population ...

oh your saying that the fact all the people doing it are foreigners paid by democrats, or are microsoft gov employees, is not a coincidence ?

that cant be true. that would be un-constitutional.

Google: statistical attack

About 92,500,000 results

mostly papers by gov workers learning how to do them, i might guess

you never see investigations and papers written by people who would never do such a thing - i guarantee it

Evaluating Statistical Attacks on Personal ... - Joseph Bonneau
www.jbonneau.com/doc/BJM10-FC-name_guessing_statistics.pdf

We study the efficiency of statistical attacks on human au- thentication .... one specific user in a targeted attack, or may be content to gain access on behalf

------------
reaaly. and is your screen name and IP your real one, or are you from somewheres else and covering up your tracks?

well in BSD they used to do regression tests to insure quality

i cant beleive in CA their are foreigners being paid to delete tests and add troubles to american software while hording untained versions using huge government mainframes in their own countries to compete against USA intel

beleive what u want - done

Shortly, the search path for shared libraries. It used to be big deal and difficult to get right if you install anywhere but the standard system locations.