© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
> I don't know if this is expected behavior, but it's certainly annoying behavior. I'm writing an app that depends on libtcodxx.so, which in turn depends on libtcod.so. I want to ship them both in the lib directory next to my app. With RUNPATH as "$ORIGIN/lib", it finds the direct dependency (libtcodxx.so) and then doesn't look in the same directory for its dependency. To get it to search there for both, I have to set RPATH to "$ORIGIN/lib", and I suspect that RPATH may not technically be supposed to support the $ORIGIN syntax.
It looks like it's the expected behaviour after all. From "Shared Object Dependencies" section in [1]:
"""
The set of directories specified by a given DT_RUNPATH entry is used to find only the immediate dependencies of the executable or shared object containing the DT_RUNPATH entry. That is, it is used only for those dependencies contained in the DT_NEEDED entries of the dynamic structure containing the DT_RUNPATH entry, itself. One object's DT_RUNPATH entry does not affect the search for any other object's dependencies.
"""
Another interesting bit in [1] is the "Dynamic Array Tags" table, where it's stated that RUNPATH is optionally considered for both shared objects and executables, while RPATH is ignored for shared objects. It seems like that suggests the idea when using RUNPATH is that you'd have both executables and shared objects specifying it, instead of setting it just for the "top level" executable and letting that work transitively.
I've investigated this a bit and it seems that the move to using --enable-new-dtags by default is something Debian changed explicitly a while ago:
binutils (2.27.51.
* Stop building the mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el
variants; can't continue with this work, because package uploads with
these architectures are still rejected.
* Add homepage attribute to the control file: Closes: #841432.
* ld: enable new dtags by default for linux/gnu targets. Closes: #835859.
* Fix PR ld/20827, using proposed patch. Closes: #844378.
-- Matthias Klose <email address hidden> Thu, 17 Nov 2016 11:56:55 +0100
While I understand this probably makes sense in a world where everyone is aware of these differences and either upstream projects are built considering RUNPATH (e.g. WebKitGTK+) or packagers explicitly workaround this by passing --disable-new-dtags to projects that haven't been adapted upstream yet (e.g. GNOME Shell), it still seems to me like this has huge potential to break things if it just gets enabled in other Debian-based without further consideration (and rebuilds!), so if you're having this problem and you control your platform but not every single package built on top of it, you might consider reverting the Debian patch that closes #835859 for the time being.
That's precisely what we're considering to do in Endless for now, and I thought I'd share it here in case this analysis was useful for someone else, if anything as a sign of gratitude for this bug report in itself, which was very useful for me to understand better what was going on when we first encountered this problem ourselves (similar to what was reported already in [2] and [3])
Hope this helps too!
Mario
[1] https:/
[2] https:/
[3] https:/