In general I you shouldn't set an `RPATH` on the installed binaries / libraries as a developer. However, if you're packaging for a specific distribution you know more about the target system than the original developer, and setting an `RPATH` could be a good solution. The same could be true when doing local installs in your home folder. In short, my view boils down to this: maintainers / developers shouldn't mess with `RPATH`s, but users/packagers can have valid reasons. Of course you may be both at the same time, but you should still keep the separation in mind since other users/packagers may not want an `RPATH` in the installed targets. [quote="Martin_Guenther, post:2, topic:1335"] 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: [/quote] Another option is to use a tool like `patchelf` to set an `RPATH` in the precompiled binaries. I tend to do this with closed source binaries that ship a bunch of conflicting libraries. You won't need to set `LD_LIBRARY_PATH` then. If you do prefer `LD_LIBRARY_PATH` but you can't use an `env` tag, you can use a wrapper script or call the `env` command. --- [Visit Topic](https://discourse.ros.org/t/is-it-a-good-practice-to-force-rpath-to-be-embedded-in-the-installed-targets/1335/3) 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: