On 11 February 2021 at 12:50, Johannes Ranke wrote:
| Am Donnerstag, 11. Februar 2021, 12:20:33 CET schrieb Bastian Blank:
| > Hi Johannes
|
| Hello Bastian!
|
| > On Thu, Feb 11, 2021 at 09:26:48AM +0100, Johannes Ranke wrote:
| > > dyn.load is used in base R to load compiled code from R packages.
| >
| > Can you show some examples please? I know C and POSIX, but not much
| > about R.
|
| Well, in a nutshell, loading a package in R means calling library [1] which
in
| turn calls loadNamespace [2] which, if the package uses compiled code, calls
| library.dynam [3], which uses dyn.load [4] after normalizing the path to the
| DLL.
|
| So if you load e.g. the package MASS in R, dyn.load is called:
|
| R> debug(dyn.load)
| R> library(MASS)
| debugging in: dyn.load(file, DLLpath = DLLpath, ...)
| debug: .Internal(dyn.load(x, as.logical(local), as.logical(now), ""))
| Browse[2]> x
| [1] "/usr/local/lib/R/site-library/MASS/libs/MASS.so"
|
| ...
|
| > > The documentation of dyn.load says that it accepts a path to a dynamic
| > > shared object. Do we need more than that?
| >
| > So my change is no problem, because it only changes the behaviour for
| > 'dyn.load("object.so")', but not for
| > 'dyn.load("/home/foo/projects/bar/object.so")'.
| >
| > The documentation does not list a search behaviour for bare library
| > names on non-Windows systems. So completely ignoring the system library
| > paths is kind of weird.
|
| I can see that it looks weird - but is it a bug?
Exactly. It has been like that since the 1990s when R's packaging system was
set up. We have hundreds of per package shared libraries. Even the first one
I packaged for Debian (r-cran-rodbc, in 2003 if memory serves) used that.
"A feature not a bug" :)
Dirk
| Johannes
|
| [1] https://github.com/wch/r-source/blob/trunk/src/library/base/R/
| library.R#L54
|
| [2] https://github.com/wch/r-source/blob/trunk/src/library/base/R/
| namespace.R#L185
|
| [3] https://github.com/wch/r-source/blob/trunk/src/library/base/R/
| library.R#L572
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
