# Set the RUNPATH of installed shared libraries to "$ORIGIN"
**URL:** https://discourse.vtk.org/t/set-the-runpath-of-installed-shared-libraries-to-origin/6234
**Category:** Development
**Tags:** proposal
**Created:** [July 24, 2021, 9:54am UTC](https://discourse.vtk.org/t/set-the-runpath-of-installed-shared-libraries-to-origin/6234 "2021-07-24T09:54:56Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@Wile\_E\_Coyote](https://discourse.vtk.org/u/Wile_E_Coyote)
#### Post date: [July 24, 2021, 9:54am UTC](https://discourse.vtk.org/t/set-the-runpath-of-installed-shared-libraries-to-origin/6234/1 "2021-07-24T09:54:56Z")
This is Ubuntu 20.04.2 LTS / x86\_64 / gcc 9.3.0 here.
When I build the “VTK-9.0.3”, all its shared libraries get the “`RUNPATH`” pointing to the `"/.../build/lib"` directory.
However, the “make install” resets the runtime path of all installed “`/.../lib/libvtk*.so`” shared libraries to `""`.
Could you, please, consider changing this behavior so that the “`RUNPATH`” of “installed” shared libraries would be set to `"$ORIGIN"`.
Note: the python related “`site-packages/vtkmodules/vtk*.so`” already get the runtime path `"$ORIGIN/../../../"` and also the executables “`bin/vtk*`” get `"$ORIGIN/../lib"`.
---
### Author:  [@kalvdans](https://discourse.vtk.org/u/kalvdans)
#### Post date: [July 24, 2021, 8:52pm UTC](https://discourse.vtk.org/t/set-the-runpath-of-installed-shared-libraries-to-origin/6234/2 "2021-07-24T20:52:59Z")
Why would you need rpath to be set on installed libraries? I’ve only seen rpath with $ORIGIN when a program is bundled with its libraries so that it can be unpacked anywhere in the hierarchy.
---
### Author:  [@Wile\_E\_Coyote](https://discourse.vtk.org/u/Wile_E_Coyote)
#### Post date: [July 24, 2021, 9:33pm UTC](https://discourse.vtk.org/t/set-the-runpath-of-installed-shared-libraries-to-origin/6234/3 "2021-07-24T21:33:40Z")
Yes, that’s more or less my case.
I’d like to “dlopen” VTK shared libraries from a running application, and I would like to spare myself the trouble of maintaining “`LD_LIBRARY_PATH`”.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [July 24, 2021, 11:50pm UTC](https://discourse.vtk.org/t/set-the-runpath-of-installed-shared-libraries-to-origin/6234/4 "2021-07-24T23:50:40Z")
You can set `CMAKE_INSTALL_RPATH=$ORIGIN` when building VTK to add it to every library at least.
That said, VTK probably should set it for itself at least since it does ship a “few” libraries it knows will be beside each other.
---
### Author:  [@Wile\_E\_Coyote](https://discourse.vtk.org/u/Wile_E_Coyote)
#### Post date: [July 25, 2021, 10:46am UTC](https://discourse.vtk.org/t/set-the-runpath-of-installed-shared-libraries-to-origin/6234/5 "2021-07-25T10:46:03Z")
Yes, I know I can use: `cmake -DCMAKE_INSTALL_RPATH="\$ORIGIN"`
However, I am more thinking about the default VTK behavior.
So that, when one tries to use this software compiled by somebody else, one will not need to fight with this “problem”.
An additional quirk of manually setting such a “`CMAKE_INSTALL_RPATH`” is that, the installed “`/.../lib/libvtk*.so`” shared libraries get `"$ORIGIN"` but simultaneously, the python related “`site-packages/vtkmodules/vtk*.so`” get `"$ORIGIN:$ORIGIN/../../../"` and also the executables “`bin/vtk*`” get `"$ORIGIN:$ORIGIN/../lib"`.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [July 25, 2021, 12:51pm UTC](https://discourse.vtk.org/t/set-the-runpath-of-installed-shared-libraries-to-origin/6234/6 "2021-07-25T12:51:47Z")
[This MR](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8210) adds `$ORIGIN` internally to the modules at least (executables will still have it as an “extra” path).
---
### Author:  [@kayarre](https://discourse.vtk.org/u/kayarre)
#### Post date: [November 4, 2021, 10:05pm UTC](https://discourse.vtk.org/t/set-the-runpath-of-installed-shared-libraries-to-origin/6234/7 "2021-11-04T22:05:47Z")
how should this work with libraries like libTBB.so?
for building vtk its not a problem, but with something donstream uses vtk (vtl built with TBB). the downstream can’t find the TBB library.
I tried setting CMAKE\_INSTALL\_RPATH for TBB and VTK to the install/lib directories. things still only work when I set LD\_LIBRARY\_PATH to the TBB lib directory.
I saw this post [[vtk shared library lookup on linux](https://discourse.vtk.org/t/vtk-shared-library-lookup-on-linux/5997)]([vtk shared library lookup on linux - #3 by Harald\_Scheirich](https://discourse.vtk.org/t/vtk-shared-library-lookup-on-linux/5997/3)). but using `(CMAKE_INSTALL_RPATH $Origin) `
I am a bit confused.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [November 5, 2021, 2:45pm UTC](https://discourse.vtk.org/t/set-the-runpath-of-installed-shared-libraries-to-origin/6234/8 "2021-11-05T14:45:39Z")
Setting up rpath entries for external libraries is very dependent on the deployment setup. Packaging systems like Spack, Anaconda, or vcpkg already have ways to have packages find their dependencies. For custom builds, it’ll need to be figured out. The “easy way” is to just tell CMake to use the build rpath for the install rpath too with [`CMAKE_INSTALL_RPATH_USE_LINK_PATH`](https://cmake.org/cmake/help/latest/prop_tgt/INSTALL_RPATH_USE_LINK_PATH.html). This only works if nothing will move after installation happens.