On 12 Aug 2014 09:16, Brennan Shacklett wrote:
> Bug 17251 deals with (what I believe is) the incorrect calculation of $ORIGIN
> for shared libraries. Currently $ORIGIN is calculated correctly for executables
> on linux, because readlink is called on /proc/self/exe, which means the
> resulting path is absolute and has no symlinks. 

i'm not sure this behavior is even correct (see below), but at the same time, 
i'm not sure there's a reasonable way to implement the correct behavior.

> Shared libraries with relative paths on the other hand are based 
> off of appending the name / path of the library to the current working 
> directory, which means if the library is a symlink, it is not followed, which 
> breaks RPATH $ORIGIN in the following scenario:

using the current working directory to fill in $ORIGIN surely is incorrect.  the 
ELF spec states:
	When the dynamic linker loads an object that uses $ORIGIN, it must calculate 
	the pathname of the directory containing the object.

which means i'm not sure that's justification for doing a full path resolution.  
if the library is located in ~/, then $ORIGIN inside that lib means it should 
search in ~/ (and not wherever getcwd returns).  although the spec does provide 
enough wiggle room to say either implementation is conforming ...

you do have a case that $ORIGIN should behave the same regardless of the object 
using it (the main executable or a shared lib).  i wonder if the $ORIGIN usage 
in the main ELF breaks if you utilize the ld.so directly if it's utilizing the 
/proc/self/exe symlink ...
$ /lib64/ld-linux-x86-64.so.2 /bin/sh
sh-4.3$ ls -l /proc/$$/exe
lrwxrwxrwx 1 vapier users 0 Mar  2 02:19 /proc/8304/exe -> /lib64/ld-2.21.so
-mike