Summary: | $ORIGIN in shared library's rpath not used to find library dependencies at link time | ||
---|---|---|---|
Product: | binutils | Reporter: | Steven Vormwald <sdvormwa> |
Component: | ld | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | fweimer, prg |
Priority: | P2 | ||
Version: | 2.23 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
Steven Vormwald
2014-05-12 17:09:29 UTC
(In reply to Steven Vormwald from comment #0) > ${CUSTOM_LD_PATH}/x86_64-unknown-linux-gnu/bin/ld: warning: libbar.so, > needed by lib//libfoo.so, not found (try using -rpath or -rpath-link) > lib//libfoo.so: undefined reference to `bar' > collect2: ld returned 1 exit status Oops, cut-and-paste error here. I copied and edited (to remove employer-specific paths) the failure from before I tried building a version of the library without $ORIGIN. Here's the correct error: ${CUSTOM_LD_PATH}/x86_64-unknown-linux-gnu/bin/ld: warning: libbar.so, needed by lib//libfoo_origin.so, not found (try using -rpath or -rpath-link) lib//libfoo_origin.so: undefined reference to `bar' collect2: ld returned 1 exit status (In reply to Steven Vormwald from comment #0) > GNU ld (GNU Binutils) 2.23.1 This problem also occurs in 2.24. 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 |