explict sharing of symbols between packages

[Duncan Temple Lang]

Hi Richard.

 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.



Richard.Beare@csiro.au wrote:
> 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
> package.
> 
> Is there any way to define a group of packages that share a
> symbol table? That would seem to me to be a possible
> solution.
> 
> Can anyone offer advice on this?
> 
> Thanks
> 
> -- 
> Richard Beare, CSIRO Mathematical & Information Sciences
> Locked Bag 17, North Ryde, NSW 1670, Australia
> Phone: +61-2-93253221 (GMT+~10hrs)  Fax: +61-2-93253200
> 
> Richard.Beare@csiro.au
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> 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
> _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

-- 
_______________________________________________________________

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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._