dyn.load()
function which controls how
dynamically loadable libaries are integrated into an R process. These
are `local
' and `now
'.
These control whether
TRUE
and
TRUE
indicating that the symbols are loaded
locally and resolved on immediately the DLL is loaded.
To test these flags, we have 2 libraries: Central.so, T.so.
T.so has a routine,
foo()
that requires a
symbol Rso()
available in Central.so
We first examine the effect of lazy loading, deferring the resolution of the undefined symbols until they are needed.
Now, let's look at the sharing of symbols between libraries. We saw that if we attempt to load the library# Missing symbol R.so.
> dyn.load("T.so") # Fails, missing symbol Rso# lazy loading
> dyn.load("T.so", , now = FALSE) # Success, but don't call foo(). > .C("selfReliant")In selfReliant() (bar.c in T.so) list()
T.so
using the default argument values, we are missing the symbol Rso()
. This is available in Central.so
.
Restart R.
> dyn.load("Central.so")Now, start R again.# default arguments so loads locally
> dyn.load("T.so")# Fails since Rso is not globally accessible.
> dyn.load("Central.so", local = FALSE)Note that the symbols in# load globally
> dyn.load("T.so")# success.
T.so
do not have to be
loaded globally, just to the donor Central.so
DLL. Now we can call foo()
in T.so
and all the symbols will be resolved correctly.
> .C("foo")
Second External foo()
In Rso.
list()
tar zxvf R-dynload.tar.gzwill extract its contents.