Why does tch-rs use LD_LIBRARY_PATH instead of rpath?

1

I am using export LIBTORCH_USE_PYTORCH=1 so that tch-rs detects the location of the C++ library libtorch_cpu.so during cargo build; see

When I run a program that uses tch-rs it seems I have to set LD_LIBRARY_PATH to the directory containing the torch library. Some people consider this a security risk and like to bind the location of the library during the build using rpath.

Is there a reason that tch-rs does not use rpath and instead prefers to have each user specify the LD_LIBRARY_PATH (perhaps this is not possible when linking rust to C++) ?

2

You wouldn't need to use LD_LIBRARY_PATH if libtorch is installed globally. And if it is local, then using rpath would break whenever the executable or libtorch gets moved around. I don't know if that is the actual reason tch-rs made this decision. You did have to ask one of the maintainers.

3

Using rpath makes sense if you are producing “binary for sale”, essentially. It just complicates things. You can use $ORIGIN to specify relative path — but that becomes problematic when you build shared library that depends on the other shared library: “middle layer” have to know where all other libraries relative to binary, not relative to shared library itself. That's doable and supportable on CI when your goal is to produce something you may sell (or just distribute to others), but if you build an internal tool then LD_LIBRARY_PATH is just simpler and more versatile.

4

One thing I like about rpath is that you only have to know the location of the libraries you use, if they use rpath, they will automatically connect to thier dependencies.

5

I am using a pip install of libtorch, and removed my system install, because my system install was too old to work with the current tch-rs.

6

Cargo doesn't support post-build operations and I don't think there's a built-in option to set rpath when the program is built. Also static linking means if tch-rs were to set rpath it would affect the entire executable, not just the library itself.

7

If I understand you correctly, there is no way that cargo can link a C++ dynamic library using something equivalent to rpath; i.e., where the directory containing the library is specified at build time (instead of run time) ?

8

There are ways to pass arbitrary linker flags, but it's not really an option available to third-party crates, no. Last I checked the easiest way to deal with rpath was to run patchelf after you've built the executable.