Talk:Rpath

Untitled

The link given in the text (http://people.debian.org/~che/personal/rpath-considered-harmful) gave a 404 error for me. I propose removing the link if the problem persists (e.g. is reproducable in a few days). --134.76.88.73 (talk) 21:51, 23 October 2008 (UTC)[reply]

Does it override LD_LIBRARY_PATH ?

The quoted Debian article explains that one can use LD_LIBRARY_PATH to fix a RPATH setting, which does not match the system at hand. Can the claim in this article be fixed please? Or explained in more detail? Or is the Debian article wrong? —Preceding unsigned comment added by 95.89.56.34 (talk) 17:39, 5 November 2010 (UTC)[reply]

Thanks for giving this comment! I did not discover this issue in that Debian article before. I will try to fix the wrong information there. The problem is that -rpath behaves differently on whether the linker (ld) has the "new-dtags" feature enabled.

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, which is checked by the dynamic linker at run time and if it finds an DT_RUNPATH, attribute, it ignores the value of DT_RPATH, which 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 in this configuration, the paths in LD_LIBRARY_PATH *are* searched before these given at link time using -rpath if --enable-new-dtags was active. Bernhard.kaindl (talk) 13:58, 12 October 2011 (UTC)[reply]

@95.89.56.34 - I think you have the wrong end of the stick... A rpath does not allow LD_LIBRARY_PATH overrides. A runpath does allow LD_LIBRARY_PATH overrides.

Jeffrey Walton (talk) 06:20, 22 June 2020 (UTC)[reply]

Enhanced the article to give more (correct) detail

There was a mini-edit-war between User:Andrewg at cray and everybody else. Andrewg at cray, based on a web page which he found and a test he did on his SUSE Linux, claimed that rpath can be overridden by LD_LIBRARY_PATH on Solaris and Linux, but this was in fact only true for Solaris.

On Linux, this is only true of the GNU ld's new-dtags feature is enabled, which is not the default of GNU ld, but some distributions builds (maybe SUSE) or some builds (using --enable-new-dtags) may enable this feature.

The bottom line is: The different dynamic linkers for ELF implement the use the DT_RPATH entry in different ways and there are several information pages found in the WWW which try to explain rpath and make the impression to be authoritative, while what they say only applies to a given observation these users made on their systems.

Some incorrectly state that LD_LIBRARY_PATH overrides rpath on Linux and Solaris which is a completely confused statement because dynamic linking not carried out by the operating system's kernel but the dynamic linker used to run the program. This means it is dependent on the implementation of the dynamic linker, how it interprets the DT_RPATH entries found in ELF files during linking. In addition, one does not override the other, it only is searched before or after the other. Using the term "overrides" is also misinforming because one does not override the other, it is only searched before the other. E.g. the dynamic linker of SunOS still looks in the directory found in the DT_RPATH entry if a given library is not found in LD_LIBRARY_PATH.

I have therefore removed the wrong information and the links to pages with wrong information to prevent further confusion added correct information with reference. Bernhard.kaindl (talk) 13:58, 12 October 2011 (UTC)[reply]

Class object

rpath falls into a category of assembler level options that can be used to craft cascade failure of a unix line

Make the article executable-format-unbiased by moving references to specific formats to subsections

In the introduction already the format ELF is mentioned, but this is only one of many possible executable formats which can be dynamically linked. Stay operating system agnostic in general sections of the articles, and cover specifities only in subsections. Felixbecker2 (talk) 07:52, 6 August 2019 (UTC)[reply]

The article is a bit unclear with respect to GNU Linux

I think this article is a bit unclear with respect to GNU Linux. I think it may even present some incorrect information.

On a GNU Linux system there are two paths that can be embedded in an executable or library. First path is a rpath, and second is a runpath. You add a rpath with -Wl,-rpath,<path>. A rpath is not overrideable by LD_LIBRARY_PATH. Then second path is a runpath. You add a runpath with -Wl,-rpath,<path> -Wl,--enable-new-dtags. A runpath is overrideable by LD_LIBRARY_PATH.

So the only difference between a rpath and a runpath is whether the path is overrideable by LD_LIBRARY_PATH, and that comes from whether -Wl,--enable-new-dtags is present or not.

Executables and libraries using a runpath and built with -Wl,--enable-new-dtags do not have both rpath (DT_RPATH) and runpath (DT_RUNPATH). They only have runpath (DT_RUNPATH), and the path is overrideable by LD_LIBRARY_PATH.

As an example, here's GNU's libiconvert was built using runpaths. That is, LDFLAGS used -L/tmp/ok2delete/lib -Wl,-R,'$ORIGIN/../lib' -Wl,-R,/tmp/ok2delete/lib -Wl,--enable-new-dtags. The paths can be inspected with the following. Notice there is only a runpath (DT_RUNPATH).

$ readelf -d /tmp/ok2delete/bin/iconv | grep -E 'rpath|runpath'
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/tmp/ok2delete/lib]

Software built nowadays that has an embedded path is recommended to use -Wl,--enable-new-dtags. That is, you should enable LD_LIBRARY_PATH overrides.

Jeffrey Walton (talk) 06:02, 22 June 2020 (UTC)[reply]

What the hell is happening in Example

Besides glaringly insane phrasing of "if libtermcap.so is in /lib and called libtermcap.so.4" (what! (also where did libtermcap.so come from?)) this references some bizarre scenario, something about the shell(?), file operations that make no sense, how is Linux relevant in the solaris-phrased thing, there's a blog halfway through, ...?! Nabijaczleweli (talk) 01:48, 23 May 2024 (UTC)[reply]