Oops, sorry for the empty description, firefox decided to submit the form when I hit enter.
The issue is that if a shared library has $ORIGIN in its RPATH, $ORIGIN is not calculated as the real path of the library.

This can easily be shown with two shared libraries and a symlink:

libone.so and libtwo.so are both in a directory named ~/lib
libone.so needs libtwo.so, and has an RPATH of "$ORIGIN" so libtwo.so can be found.
If I cd into ~/lib and run ldd on libone.so, libtwo.so is found.
If I create a symlink from ~/libone.so to ~/lib/libone.so, and run ldd on the symlink at ~/libone.so, libtwo.so can no longer be found because $ORIGIN is not calculated as ~ rather than ~/lib

s/is not calculated/is calculated/ in the last sentence.

Created attachment 7744 [details]
Patch to switch $ORIGIN to be calculated based on absolute path

This patch fixes the behavior for me, I'll also post it to the mailing list with an explanation.

I'm not sure if you can use __realpath from the dynamic linker.  And PATH_MAX could be too small; the __realpath function with a non-NULL second argument is basically broken.

Well I defined __realpath in dl-realpath.c and included that into rtld-routines, doesn't that allow the linker to use it?
I'm not sure what you mean about __realpath being broken with a non null 2nd argument, the version which I defined in dl-realpath doesn't even handle a NULL second argument (I didn't think it was necessary). Are you saying I should rewrite the dl-realpath version to handle that NULL and dynamically allocate its own memory?

There is a more detailed explanation in my mailing list post here: https://sourceware.org/ml/libc-alpha/2014-08/msg00160.html if you want more details.

(In reply to Brennan Shacklett from comment #5)
> Well I defined __realpath in dl-realpath.c and included that into
> rtld-routines, doesn't that allow the linker to use it?

Ah, I missed the reimplementation.  I'll post further questions to the mailing list.

Note that the gABI says:
~~~
Within a string provided by dynamic array entries with the DT_NEEDED or DT_RUNPATH tags and in pathnames passed as parameters to the dlopen() routine, a dollar sign ($) introduces a substitution sequence.
...
If the name is ``ORIGIN'', then the substitution sequence is replaced by the dynamic linker with the absolute pathname of the directory in which the object containing the substitution sequence originated. Moreover, the pathname will contain no symbolic links or use of ``.'' or ``..'' components. Otherwise (when the name is not ``ORIGIN'') the behavior of the dynamic linker is unspecified. 
~~~
http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#shobj_dependencies

It seems to me that the entire sequence, including $ORIGIN, is considered a "pathname", and that "pathname" should contain no symbolic links, ".", or ".." components.

Therefore following symlinks seems against the specification of $ORIGIN?

(In reply to Carlos O'Donell from comment #7)
> Note that the gABI says:
> ~~~
> Within a string provided by dynamic array entries with the DT_NEEDED or
> DT_RUNPATH tags and in pathnames passed as parameters to the dlopen()
> routine, a dollar sign ($) introduces a substitution sequence.
> ...
> If the name is ``ORIGIN'', then the substitution sequence is replaced by the
> dynamic linker with the absolute pathname of the directory in which the
> object containing the substitution sequence originated. Moreover, the
> pathname will contain no symbolic links or use of ``.'' or ``..''
> components. Otherwise (when the name is not ``ORIGIN'') the behavior of the
> dynamic linker is unspecified. 
> ~~~
> http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#shobj_dependencies
> 
> It seems to me that the entire sequence, including $ORIGIN, is considered a
> "pathname", and that "pathname" should contain no symbolic links, ".", or
> ".." components.
> 
> Therefore following symlinks seems against the specification of $ORIGIN?

Isn't it saying the opposite, that symbolic links must be resolved in the expansion of $ORIGIN?

(In reply to Florian Weimer from comment #8)
> (In reply to Carlos O'Donell from comment #7)
> > Note that the gABI says:
> > ~~~
> > Within a string provided by dynamic array entries with the DT_NEEDED or
> > DT_RUNPATH tags and in pathnames passed as parameters to the dlopen()
> > routine, a dollar sign ($) introduces a substitution sequence.
> > ...
> > If the name is ``ORIGIN'', then the substitution sequence is replaced by the
> > dynamic linker with the absolute pathname of the directory in which the
> > object containing the substitution sequence originated. Moreover, the
> > pathname will contain no symbolic links or use of ``.'' or ``..''
> > components. Otherwise (when the name is not ``ORIGIN'') the behavior of the
> > dynamic linker is unspecified. 
> > ~~~
> > http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#shobj_dependencies
> > 
> > It seems to me that the entire sequence, including $ORIGIN, is considered a
> > "pathname", and that "pathname" should contain no symbolic links, ".", or
> > ".." components.
> > 
> > Therefore following symlinks seems against the specification of $ORIGIN?
> 
> Isn't it saying the opposite, that symbolic links must be resolved in the
> expansion of $ORIGIN?

Oh, I see how you could interpret that.

You are saying that the phrasing "absolute pathname of the directory" means that symbolic links *must* be dereferenced?

I was looking at the phrasing "the pathname will contain no symbolic links" as meaning that the pathname *before* the expansion shall contain no symbolic links, otherwise the behaviour of the dynamic linker is unspecified. That the intent of the authors was to simplify the dynamic linker implementation to not have to handle the path expansion and symbolic link following to compute the path name.

Which interpretation was yours?

Symbolic links must be resolved, like realpath.

(In reply to Andreas Schwab from comment #10)
> Symbolic links must be resolved, like realpath.

Is your suggestion that the final absolute path computed from the DT_NEEDED or DT_RPATH or DT_RUNPATH, contain a path that has no symbolic links or back/current references?

As written in the gABI, $ORIGIN must be fully resolved.  This is unambigous.

(In reply to Andreas Schwab from comment #12)
> As written in the gABI, $ORIGIN must be fully resolved.  This is unambigous.

I agree.

I'm not going to fix this issue in my current round of cleanups, it's sufficiently orthogonal that it can be cleaned up later. Though I am fixing bug 23102, and bug 23259 (with a patch based on your Fedora patch).