explict sharing of symbols between packages
Duncan Temple Lang
Mon, 9 Sep 2002 05:52:47 -0400
This issue arises reasonably often. Doug Bates has brought it up on a
few occassions, specifically related to packages that want to use
routines that are located in R modules (lapack). And many of the
Omegahat packages are naturally split into different packages that
share a set of common routines.
As you point out, you can use
dyn.load("foo.so", local = FALSE)
to get the symbols in foo.so directly into
the global symbol table and make them available
to other dynamically loaded code.
This can introduce a whole range of other problems
There are a few different approaches you can use.
a) Put the common code into a native library (e.g. libCommon.a or libCommon.so)
and then arrange to have each of the packages that use these routines
link against this. For Windows, you will explicitly export the symbols
that are to be shared from this library.
In this model, the library of common routines (libCommon.so) is not
used dynamically loaded by R. Instead is one step removed, being
linked into .so's or .dll's that are.
This is probably the most practical approach. However, it will require
that you set your LD_LIBRARY_PATH (or PATH on Windows) variable
to include the directory containing libCommon.so/dll so that the dynamic loader
can find it at run time.
Also, if you use global variables in the common library, some systems
require coaxing to ensure that there is only one instance of those variables
shared across all the different libraries.
b) If you really want to have
I have some example packages that illustrate this. If there is
interest, I will tidy them up and write up a more complete description
of the different approaches.
Kurt Hornik and I have agreed to implement a mechanism after R 1.6 is
released. It will probably use one or more of these approaches and
make them much easier.
> Hi everyone,
> I'm thinking about breaking up a large package I have to
> avoid loading some of the more specialised parts when it
> isn't necessary.
> The package is dependent on shared libraries. The base one
> will keep all of the core stuff like constructors etc and
> the specialised parts will need to access these. It is
> obviously possible to set the "local" flag to false, however
> this becomes a dangerous, especially with the larger
> Is there any way to define a group of packages that share a
> symbol table? That would seem to me to be a possible
> Can anyone offer advice on this?
> Richard Beare, CSIRO Mathematical & Information Sciences
> Locked Bag 17, North Ryde, NSW 1670, Australia
> Phone: +61-2-93253221 (GMT+~10hrs) Fax: +61-2-93253200
> 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: email@example.com
Duncan Temple Lang firstname.lastname@example.org
Bell Labs, Lucent Technologies office: (908)582-3217
700 Mountain Avenue, Room 2C-259 fax: (908)582-3340
Murray Hill, NJ 07974-2070
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: email@example.com