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.
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.
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.