Bug 8316

Summary:	lttng-tools and lttng-babeltrace executables contain bad RPATH pointing to host machine
Product:	buildroot	Reporter:	Ben Shelton <benjamin.h.shelton>
Component:	Other	Assignee:	unassigned
Status:	RESOLVED INVALID
Severity:	normal	CC:	buildroot
Priority:	P5
Version:	2015.05
Target Milestone:	---
Hardware:	PC
OS:	Linux
Host:		Target:
Build:

Description Ben Shelton 2015-08-27 16:29:28 UTC

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@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@buildroot cli]# cd
[root@buildroot ~]# umount /workspace
[root@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.

Comment 1 Thomas Petazzoni 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.

Comment 2 Thomas Petazzoni 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.