[Bug ld/16936] $ORIGIN in shared library's rpath not used to find library dependencies at link time

[prg at ichthyostega dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=16936

Ichthyostega <prg at ichthyostega dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |prg at ichthyostega dot de

--- Comment #3 from Ichthyostega <prg at ichthyostega dot de> ---
Can confirm this problem on Debian/Jessie X86_64, which uses binutils 2.25

We build our software such that it can be executed from a subtree, without the
need for explicit installation into the system. We have several shared modules,
with transitive dependencies. And we set up the RPATH with $ORIGIN and a
relative path spec. (Actually, its the RUNPATH, since we link with
--enable-new-dtags )

We link with --no-undefined and --as-needed. This whole setup worked in the
past (on Debian/Wheezy) without problems. But now, linking any executables
fails, which need to locate transitive dependencies this way.

If we "help" the linker with --rpath-link and an explicit location within the
build tree, the resulting executable is still able to locate the transitive
dependencies at runtime as intended.


Incidentally, note that the new version of ld does no longer include the RPATH
when --enable-new-dtags is given. So there *was* some change in this area, not
sure if this observation is relevant in any way to our problem here

-- 
You are receiving this mail because:
You are on the CC list for the bug.