[ros-users] [Discourse.ros.org] [Release] Is it a good practice to force `RPATH` to be embedded in the installed targets?

Maarten de Vries ros.discourse at gmail.com
Thu Feb 16 09:38:53 UTC 2017

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:

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.

More information about the ros-users mailing list