# RPATH and LD\_LIBRARY\_PATH when using ParaView; conflicts with libraries from other application

**URL:** https://discourse.paraview.org/t/rpath-and-ld-library-path-when-using-paraview-conflicts-with-libraries-from-other-application/6259
**Category:** Development
**Created:** [January 21, 2021, 8:03am UTC](https://discourse.paraview.org/t/rpath-and-ld-library-path-when-using-paraview-conflicts-with-libraries-from-other-application/6259 "2021-01-21T08:03:17Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![menno](https://discourse.paraview.org/user_avatar/discourse.paraview.org/menno/32/1127_2.png) [@menno](https://discourse.paraview.org/u/menno)
#### Post date: [January 21, 2021, 8:03am UTC](https://discourse.paraview.org/t/rpath-and-ld-library-path-when-using-paraview-conflicts-with-libraries-from-other-application/6259/1 "2021-01-21T08:03:17Z")

</div>

I’m trying to understand what is going on with the following: we have a simulation code that uses specially-built paraview libraries for in-situ processing. The executable finds its libraries using `LD_LIBRARY_PATH`.  
On the same machine, there is also ParaView installed (same version, 5.8, installed as pre-built binaries), that has built-in RPATH definition for finding its libraries: `RPATH $ORIGIN/../lib:$ORIGIN/../lib64`

The problem we’re facing is that when paraview executable is started, while the in-situ libraries are on the LD\_LIBRARY\_PATH, paraview crashes.

From my limited understanding of RPATH, I thought that RPATH takes precedence over LD\_LIBRARY\_PATH, but that does not seem to be happening here.

Do you have any advice on how to resolve this? One thing we could do, I suppose, is to also use RPATH in the executable of the simulation. But if there is a simpler way to convince the loader to first use RPATH that would be great.

---

<div class="post-metadata">

### Author: ![mwestphal](https://discourse.paraview.org/user_avatar/discourse.paraview.org/mwestphal/32/17_2.png) [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [January 22, 2021, 9:00am UTC](https://discourse.paraview.org/t/rpath-and-ld-library-path-when-using-paraview-conflicts-with-libraries-from-other-application/6259/2 "2021-01-22T09:00:24Z")

</div>

@ben.boeckel

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [January 22, 2021, 2:33pm UTC](https://discourse.paraview.org/t/rpath-and-ld-library-path-when-using-paraview-conflicts-with-libraries-from-other-application/6259/3 "2021-01-22T14:33:24Z")

</div>

> [@menno](#):
>
> From my limited understanding of RPATH, I thought that RPATH takes precedence over LD\_LIBRARY\_PATH, but that does not seem to be happening here.

`DT_RPATH` does, but `DT_RUNPATH` does not (and is _why_ `DT_RPATH` was deprecated). You can see what is being used with `readelf -d $library` and looking for the `DT_` key in use for the paths.

> [@menno](#):
>
> But if there is a simpler way to convince the loader to first use RPATH that would be great.

Nope. `LD_LIBRARY_PATH` is a blunt tool and affects an entire process tree. I would recommend setting the `RPATH` in the simulation code to stick to the ParaView it was built against (at least by default).

---

<div class="post-metadata">

### Author: ![menno](https://discourse.paraview.org/user_avatar/discourse.paraview.org/menno/32/1127_2.png) [@menno](https://discourse.paraview.org/u/menno)
#### Post date: [January 22, 2021, 2:59pm UTC](https://discourse.paraview.org/t/rpath-and-ld-library-path-when-using-paraview-conflicts-with-libraries-from-other-application/6259/4 "2021-01-22T14:59:29Z")

</div>

Ok, thanks for clearing that up. I will see that the simulation code also gets RPATH/RUNPATH, that seems to be the best way forward.