5 ms·

Torch probably doesn't even need to set LD_LIBRARY_PATH. If LD_LIBRARY_PATH is only being set so that binaries distributed by torch work, then I'd strongly sug

Torch probably doesn't even need to set LD_LIBRARY_PATH. If LD_LIBRARY_PATH is only being set so that binaries distributed by torch work, then I'd strongly suggest they use RUNPATH instead with $ORIGIN. There are examples in various places: https://enchildfone.wordpress.com/2010/03/23/a-description-of-rpath-origin-ld_library_path-and-portable-linux-binaries/ https://enchildfone.wordpress.com/2010/03/23/a-description-o... http://man7.org/linux/man-pages/man8/ld.so.8.html http://man7.org/linux/man-pages/man8/ld.so.8.html http://longwei.github.io/rpath_origin/ http://longwei.github.io/rpath_origin/ LD_LIBRARY_PATH is really only for a developer's local use; it should never be used for installed software. Disclaimer: may not apply in some scenarios, I haven't used Torch, so this is merely a general observation.

catdog 9y ago
This nice and clean solution is too little known I think. Far better than shipping shell scripts which are very hard to get right and most application developers are not shell scripting experts.
- pjc50 9y ago
  RPATH is very nice, but it's a huge pain to set in Makefiles because you have to reliably escape the "$ORIGIN"
  - Spivak 9y ago
    (Don't do this) You could patch the binary after compilation with elfpatch. Also, test: echo "\$$ORIGIN" outputs $ORIGIN. $$ translates to a literal dollar sign. \ escapes the dollar sign in the shell.
    - binarycrusader 9y ago
      You can use elfedit instead, but really, it's not that much of a pain to just do it right in the first place.
sevensor 9y ago
I've wrestled with this in the past, and I eventually got things working to my satisfaction by reading the man page, but these blog posts bring a lot of clarity. Thanks for linking them!