As you suspect, this won't work when binary packages are built on the build farm. The generated binaries will include the full path to where `libarcontroller.so` was on the build farm, which will not be where it is on the machine where you install the .deb. So while building would work, the installed version will be unusable. Usually, one would simply ensure that all required libraries are properly installed into a location on the `LD_LIBRARY_PATH`, but as you said you can't do that: > The rational behind this is to prevent some of the libraries that are custom built as part of the SDK (e.g. curl and libressl) to be picked up by other ROS packages by accident. I have a similar problem, where the manufacturer provides precompiled libraries that interfere with system libraries (such as Qt) and therefore must not be on the `LD_LIBRARY_PATH` for the other packages. My "solution" is to only set the `LD_LIBRARY_PATH` for the node when it's launched: https://github.com/uos/basler_tof/blob/810c8aee1b396d1ad46e785c1aca3859adf360f9/launch/includes/device.launch.xml#L26 This is however a very dirty hack (for starters, the `env` launch file tag has been deprecated since Fuerte), and I would be interested in a proper solution as well. --- [Visit Topic](https://discourse.ros.org/t/is-it-a-good-practice-to-force-rpath-to-be-embedded-in-the-installed-targets/1335/2) or reply to this email to respond. If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates. ______________________________________________________________________________ ros-users mailing list ros-users@lists.ros.org http://lists.ros.org/mailman/listinfo/ros-users Unsubscribe: