RPATH and LD_LIBRARY_PATH when using ParaView; conflicts with libraries from other application

[menno (Menno Deij - van Rijswijk)]

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.

[mwestphal (Mathieu Westphal (Kitware))]

@ben.boeckel

[ben.boeckel (Ben Boeckel (Kitware))]

@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).

[menno (Menno Deij - van Rijswijk)]

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.