I keep getting the following error when attempting to install readxl
or haven
in R (both dependencies of tidyverse
) post-compilation, when the installer runs the loading test:
** testing if installed package can be loaded
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared object '<my_lib_Path>/readxl/libs/readxl.so':
<my_lib_path>/readxl/libs/readxl.so: undefined symbol: libiconv
Error loading failed
I have libiconv.so
in a local lib path (not for R packages) that is included in LD_LIBRARY_PATH
and I've verified in my R session that Sys.getenv("LD_LIBRARY_PATH")
has that directory.
Why can't R's dynamic library loader find this shared object? Is there a different R-specific environment variable I need to define to have the dynamic library loader in R search my local lib path?
Please note that this is not an issue with an R library path, but instead for a non-R dependency that an R package has. If I were compiling and linking C++ code, gcc
would use ld
, and hence LD_LIBRARY_PATH
to track down dynamic dependencies. R doesn't appear to respect this rather common approach, and I can't seem to find any documentation on how to manage these more fine-grained dependency issues.
Additional Details
!> sessionInfo()
R version 3.3.3 (2017-03-06)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
>
I had previously compiled libiconv
because it was a dependency for something else (don't recall what now - likely not an R package given current problems). I tried reinstalling it, but made no difference.
Edit
I have also tried manually loading the library prior to installation:
> dyn.load(".local/lib/libiconv.so")
> is.loaded("libiconv")
[1] TRUE
> install.packages("tidyverse")
but it fails just as above.
Normally, the iconv
method is picked up from glibc
, which is linked to during build of the R packages in question. For whatever reason, however, iconv
is getting resolved to libiconv
in this case, but it is not linked by the R packages during build.
Original Workaround
One can make the linking to libiconv
explicit by adding the following line to the haven/src/Makevars
source file
PKG_LIBS=-liconv
which then let's you install from source R CMD INSTALL haven
. However, editing packages feels hacky, plus this is something that will need to be done every upgrade, which sounds like a hassle.
Cleaner Workaround
Another option is to use withr::with_makevars
, which allows one to temporarily control Makevars
content. With this technique, one can install directly from the repo:
withr::with_makevars(c(PKG_LIBS="-liconv"), install.packages("haven"), assignment="+=")
Credit: @knb suggested that I inspect the readxl.so
with ldd
and this turned out to be super useful because it showed that the shared object wasn't even trying to link to libiconv. Knowing that, I realized I could manually add the reference via the -liconv
flag. Thanks @knb!
Additional Info
On the package side of things, relevant details about connecting libraries to R packages can be found in the guide for building libraries. On the system configuration side, the R-admin guide has some useful sections.
Are you running the code in RStudio Server? If so, the answer here may be useful.
I used to meet a similar error while loading dynamic library. The library was in a path contained in LD_LIBRARY_PATH
. When I ran the code in R console, it could load the dynamic library correctly. But when I ran it in RStudio, the same error in your post raised.
The reason is that RStudio Server has its own library search path environment. You should specify the following configuration in /etc/rstudio/rserver.conf
:
rsession-ld-library-path=/usr/lib64/:/usr/local/lib/:OTHER_PATH_OF_YOUR_LIB
Restart RStudio Server and the error should be fixed.
These libraries really should be standard on RH-based system too, and be found.
If you must add them to R, you have to do so before you start R. One way is via LD_LIBRARY_PATH
, a better way is to edit a file in /etc/ld.so.conf.d/
(assuming RH/CentOS have that too). Else maybe via /etc/environment
.
Edit: If /etc/
is out of reach, you can do everything below $HOME
. Standard shell instantiation works, and R has its own .Rprofile
and .Renviron
. You can have those below $HOME
for all your projects, and/or in a per-project directory---see help(Startup)
.
Did you install R via rpm or compile it yourself?
solution 1
If you have the permission to modify the R executable (shell script), you can try this:
Edit ~/.local/bin/R
or /usr/local/bin/R
or /usr/bin/R
#!/bin/bash
# Shell wrapper for R executable.
export LD_LIBRARY_PATH="<my_lib_Path>/readxl/libs/"
R_HOME_DIR=...
...
...
Solution 2
Or you may vim ~/.local/bin/R
#!/bin/bash
# Shell wrapper for R executable.
export LD_LIBRARY_PATH="<my_lib_Path>/readxl/libs/"
/usr/bin/R
then add ~/.local/bin
to your PATH
来源:https://stackoverflow.com/questions/45112506/how-to-specify-non-r-library-path-for-dynamic-library-loading-in-r