13

I have installed an R package but, in order to load it via library, the LD_LIBRARY_PATH needs to be set to the path where one of the libraries, called libhts.so.2 is located. The loading only works when editing the LD_LIBRARY_PATH before going into R, not after.

I have tried several different methods in solving this:

  1. exporting a modified LD_LIBRARY_PATH from the configure script located in the R package.
  2. Creating a soft link to the shared library within the same configure script.

Both have not worked and it seems to me that there is a variable that stores the results of the LD_LIBRARY_PATH once R is started. Maybe the solution is editing that variable.

kgui
  • 4,015
  • 5
  • 41
  • 53
  • 2
    Calling `Sys.setenv(LD_LIBRARY_PATH="/path/to/blah")` from within `R` will change the environment of any future subprocess, but not that of `R` itself (which can be seen with `ps e`). Still, [this post](http://r.789695.n4.nabble.com/R-seems-to-mangle-LD-LIBRARY-PATH-td4686672.html) seems to indicate that it makes a difference, so you could give it a try. – Hans Lub Jan 05 '17 at 21:50
  • 7
    .. or rather `Sys.setenv(LD_LIBRARY_PATH=paste("/path/to/blah", Sys.getenv("LD_LIBRARY_PATH"),sep=":")) ` in order not to clobber the existing path – Hans Lub Jan 05 '17 at 21:59
  • Setting the environment variables works! However, the loading of the library doesn't work... – kgui Jan 05 '17 at 22:32
  • 3
    The [guide](http://www.hep.by/gnu/r-patched/r-exts/R-exts_94.html) to writing R extensions says: _On Unix-alikes the paths used to resolve dynamically linked dependent libraries are fixed (for security reasons) when the process is launched (...)_. I'm afraid that means that your problem is not solvable: any solution would be considered a security risk.... – Hans Lub Jan 05 '17 at 23:39
  • I'll definitely read that but, I tried dyn.load(path_to_library) and it worked! In your opinion, what do you think about that? Would it be a security risk? – kgui Jan 05 '17 at 23:40
  • I suppose that when changing a search path you may shoot yourself in the foot (like with the classic `PATH=.:$PATH`). With `dyn.load` you give an _absolute_ pathname, so you (presumably) know exactly what you are doing. – Hans Lub Jan 06 '17 at 00:00
  • Btw, I think you should give your solution - using `dyn.load()` - as an answer, if it really did solve your problem. It would help other people, and I would certainly vote it up. – Hans Lub Jan 06 '17 at 09:00
  • @HansLub Thanks! I submitted an answer. – kgui Jan 06 '17 at 20:58
  • I'm confused as to why this is the case. The installer usually tests for loading and should have caught this during installation. Did you copy the **.so** object from someone else's R library path? I would think the proper solution here is to reinstall the package, with the correct LD_LIBRARY_PATH set during installation. – merv May 23 '18 at 16:25

1 Answers1

9

With help from Hans Lub, the way to solve the problem is by using the dyn.load() function and supplying the full path to the library:

dyn.load('path_to_library')

and then, loading via library should work.

kgui
  • 4,015
  • 5
  • 41
  • 53
  • 2
    Yes, this works BUT if you want to install a new package the installation happens in a fresh environment and there is no opportunity to use dyn.load() prior to the installation attempting to load the DLL. – Michael Henry Apr 18 '18 at 04:18
  • 1
    For example: if I install rJava referring to libjvm.so somewhere under $HOME (because I don't have root privileges) then I have to use dyn.load("/home/...../libjvm.so") prior to loading rJava. No problem. But when I try to install RJDBC the installation script attempts to load rJava and falls in a heap. – Michael Henry Apr 18 '18 at 04:20
  • 1
    @MichaelHenry You can use `withr::with_makevars` for that case, where you add an `-L/path/to/library` to the `PKG_LIBS` variable. See https://stackoverflow.com/a/45178482/570918 – merv May 23 '18 at 16:19
  • In case you can edit `$prefix/lib/R/etc/ldpaths` - e.g. when having built R from source with a user space compiler you are all set. I think the install process (of `R`) built from source is kind of broken as it does not update the load path bootstrap from the build environment. But, fortunately post editing the `etc/ldpaths` content to inject the path works for me. Is there maybe a more elegant way? – Dilettant Sep 07 '21 at 08:57