New: lttng-tools and lttng-babeltrace executables contain bad RPATH pointing to host machine

https://bugs.busybox.net/show_bug.cgi?id=8316

Summary: lttng-tools and lttng-babeltrace executables contain
bad RPATH pointing to host machine
Product: buildroot
Version: 2015.05
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
AssignedTo: unassigned at buildroot.uclibc.org
ReportedBy: benjamin.h.shelton at intel.com
CC: buildroot at uclibc.org
Estimated Hours: 0.0

The lttng-tools and lttng-babeltrace executables contain bad RPATHs pointing to the buildroot output/build directory. This happens with lttng-tools versions 2.6.0 and 2.7.0-rc1, as well as with lttng-babeltrace.

objdump -p shows the following:

RPATH /workspace/sw/bhshelto/buildroot/buildroot/output/build/lttng-tools-2.7.0-rc1/src/lib/lttng-ctl/.libs:/workspace/sw/bhshelto/buildroot/buildroot/output/host/usr/aarch64-buildroot-linux-gnu/sysroot/usr/lib:/workspace/sw/bhshelto/buildroot/buildroot/output/build/liburcu-0.8.7/.libs

This is a problem for us because /workspace is an NFS mount that we use for development builds, and we also mount it on our embedded targets. When /workspace is not mounted on the embedded target, the lttng utilities run fine, since the RPATH does not match anything. However, if I mount /workspace, I see the following:

[root at buildroot cli]# lttng stop
lttng: error while loading shared libraries:
/workspace/sw/bhshelto/buildroot/buildroot/output/build/lttng-tools-2.7.0-rc1/src/lib/lttng-ctl/.libs/liblttng-ctl.so.0:
file too short
[root at buildroot cli]# cd
[root at buildroot ~]# umount /workspace
[root at buildroot ~]# lttng stop
Waiting for data availability
Tracing stopped for session my-session

When I use patchelf to remove the RPATH, everything works as expected.

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=8316

--- Comment #1 from Thomas Petazzoni <[email protected]> 2015-08-27 18:09:01 UTC --- Thanks for your bug report.

We indeed know that some binaries/executables on the target have invalid rpath pointing to locations on the build machine. However, I believe it is not really Buildroot's fault here, but the build system of some packages that does an incorrect thing.

So far, this hasn't been a big issue since pretty much nobody has a path on the target that matches those invalid rpath. Of course, having such rpaths is ugly, but it wasn't causing any practical problem.

We have a patch series pending that takes care of cleaning up the target rpath (and also adjusting the rpath of the host binaries). See
http://thread.gmane.org/gmane.comp.lib.uclibc.buildroot/120158 and the following patches.

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=8316

Thomas Petazzoni <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #2 from Thomas Petazzoni <[email protected]> 2015-10-14 09:41:04 UTC --- As I indicated in my previous comment, since it is not really a bug. There are
plenty of packages which hardcode invalid (i.e host RPATH) in their binaries,
and that generally doesn't cause any problem.

We'll hopefully solve this problem once Samuel's work around RPATH tweaking gets merged.

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.