[R] Re: packaging a package addon

Duncan Temple Lang duncan at research.bell-labs.com
Thu Oct 30 14:46:06 CET 2003


Ross Boylan wrote:
> 
> Hoping this was only a problem for check because it didn't know how to
> load dependencies, I tried running the resulting code in a regular R
> session.  My first discovery was that dependent libraries need to be
> loaded by hand.  After I did that, when I ran my code I got
> > library("survival")
> > library("survivalrds", lib.loc="/home/ross/src/survivalrds.Rcheck/")
> Error in dyn.load(x, as.logical(local), as.logical(now)) : 
> 	unable to load shared library
> "/home/ross/src/survivalrds.Rcheck/survivalrds/libs/survivalrds.so":
>   /home/ross/src/survivalrds.Rcheck/survivalrds/libs/survivalrds.so:
> undefined symbol: cholesky2
> Error in library("survivalrds", lib.loc =
> "/home/ross/src/survivalrds.Rcheck/") : 
> 	.First.lib failed
> 
> cholesky2 is one of the entry points in survival referenced by
> survivalrds.  I tried adding an "external" to the declaration of
> cholesky2 (I think it's redundant) and redoing everything; it didn't
> help.
> 
> In short, I'm having some dynamic linkage problems.  Any suggestions? 
> (I'm on a linux system with the gcc 3.3 toolchain, but obviously it
> would be better to solve this portably).

This is a situation that will arise more frequently.  The current
package model is quite simple and only supports "independent" packages
at the C level.  

About a year ago, I did some work which would allow packages to have
dynamically loadable libraries and also have linkable libraries so
that other packages could link against them.  The idea is that one can
specify the different files in the DESCRIPTION file of the package and
the R tools would take care of building the different pieces.  Include
files that were to be made available to other packages were put in the
installed package and could be found using simple tools.  Similarly,
special compilation flags would be available to other packages.  These
other packages could then declare this package as a dependency
and get the necessary linking.

For non-technical reasons, I didn't get to commit this to the R
source.  However, I do use a hand-crafted version in the RGtk and
releated packages which share common code.  And I hope to get back to
this and put the code in place in R as we extended the current package
mechanism.   

Copying the code from survival is one short-term approach, but it is
very undesirable in the medium to long run.  Using the function
dyn.load()'s local = FALSE argument on operating systems that suppport
it, when loading survival will make its symbols visible to the C code
in your package. (There are other caveats too).

And the one robust method for doing this now is to use function
pointers.  It is possible in R to lookup the cholesky2 symbol in
survival and to pass it to C code as a function pointer that you can
use directly in your code.  This is a powerful approach in general for
parameterizing C routines with other routines or S functions.  If you
want more details/examples, let me know.  I am putting together some
tools/package to make this easier and illustrates its use.

 
 D.



> -- 
> Ross Boylan                                      wk:  (415) 502-4031
> 530 Parnassus Avenue (Library) rm 115-4          ross at biostat.ucsf.edu
> Dept of Epidemiology and Biostatistics           fax: (415) 476-9856
> University of California, San Francisco
> San Francisco, CA 94143-0840                     hm:  (415) 550-1062
> 
> ______________________________________________
> R-help at stat.math.ethz.ch mailing list
> https://www.stat.math.ethz.ch/mailman/listinfo/r-help

-- 
_______________________________________________________________

Duncan Temple Lang                duncan at 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




More information about the R-help mailing list