explict sharing of symbols between packages
Duncan Temple Lang
duncan@research.bell-labs.com
Mon, 9 Sep 2002 06:12:41 -0400
Oops. Thought I was postponing that mail and sent it instead.
So here is the alternative approach, i.e. b)
Rather than use the linker to connect the calls to the common routines
and their definitions in a secondary library (e.g. libCommon.so), you
can resolve and set the symbols yourself. Specifically, you use
function pointers in the code that calls the shared routines and then
when you load the packages, you arrange to have these variables refer
to the actual routines that you want.
For example, suppose we have two packages - A and B and A has a
routine named foo() that we want to call in the routine bar() located
in B.
So A.c has
void
foo(void) {
...
}
And B.c has
void (*foo_ptr)(void);
void
bar()
{
/* Want to call bar() */
(*foo_ptr)();
}
Given this setup, you need to have an initialization
routine in B.c that sets the value of the variable foo_ptr.
There are two ways to do this.
You can call R_FindSymbol() within C code.
Using the initialization routine in package B
void R_init_B(DllInfo *dll)
{
foo_ptr = R_FindSymbol("foo", "A", NULL);
}
Alternatively, you can do the lookup in R and pass
the address of foo() as an argument to a routine in B.
a <- getNativeSymbolInfo("foo", PACKAGE = "A")
.Call("setFoo", a, PACKAGE = "B")
And the C routine setFoo() looks something like
SEXP setFoo(SEXP address)
{
foo_ptr = R_ExternalPtrAddr(address);
return(R_NilValue);
}
This approach, compared to linking libraries, allows you to
dynamically change routines. This can be useful but is probably
overkill for your example. However, this approach does not rely
on linkers idiosyncrasies.
Hope this helps.
D.
--
_______________________________________________________________
Duncan Temple Lang duncan@research.bell-labs.com
Bell Labs, Lucent Technologies office: (908)582-3217
700 Mountain Avenue, Room 2C-259 fax: (908)582-3340
Murray Hill, NJ 07974-2070
http://cm.bell-labs.com/stat/duncan
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._