2017-06-17 18:00 GMT+02:00 Dirk Eddelbuettel <e...@debian.org>: > > On 17 June 2017 at 17:30, Iñaki Úcar wrote: > | Hi all, > | > | After googling around for a while, I found that this is a common > | problem, but still it is not clear to me how I should handle this. > | > | I have a package A, with C++ code via Rcpp, that needs an external C++ > | library libB. I have a configure script that sets > | > | PKG_CPPFLAGS=-I/path/to/B/include > | PKG_LIBS=-L/path/to/B/lib -lB > | > | in src/Makevars. Compilation and linking seem to go just fine. But then, > | > | ** testing if installed package can be loaded > | Error in dyn.load(file, DLLpath = DLLpath, ...) : > | unable to load shared object > | '/home/xxx/R/x86_64-redhat-linux-gnu-library/3.3/A/libs/A.so': > | libB.so: cannot open shared object file: No such file or directory > | > | If I set LD_LIBRARY_PATH=/path/to/B/lib, the error above is solved and > | the package is installed. But then I try to load the package with > | library(A), with LD_LIBRARY_PATH still set, and the same error > | reappears. > | > | So what is the proper and more portable way of linking a external > | library in a non-standard location? > > In short, I fear there is none. > > The _dynamic_ linker needs to know where the library is. There are defaults, > and there are ways to extend this (i.e. /etc/ld.so.conf.d/*conf on the OS I > use, or LD_LIBRARY_PATH as you used) but _none of those means are accessible > to an R package_. This is system dependent. > > A static library you can control for yourself in your package. > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Thanks, Dirk, as I had feared. However, I was wondering whether, instead of relying on the OS, it would be possible to save this non-standard location of the library at installation time and then to call dyn.load() before loading the package. Iñaki ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
