I am trying to package some code that is a tweak to the survival package. When I asked earlier, the list consensus was that it would be best to do this as a separate package, dependent on survival. This is proving a bit tricky. I have some run-time and compile time concerns. Run-time, my R code needs R code from survival, and my C code needs C functions from survival. Will this all be properly loaded by, for example, R CMD check, (assuming the proper dependency in DESCRIPTION) so that it doesn't blow up? The reason I haven't just tried it is that the compile-time issues. My C code depends on survival C code for headers. I believe that the typical target system where the package would be installed won't have these at all. Is that true? If so, what's the best way around this? Maybe stick the headers in a subdirectory and mess with the build options to include them? And hope they don't get out of sync with the real ones? -- 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
I have some mixed results to report. I went ahead and built a package with the dependency, my changed files, and a few headers. I left the headers in the same directory as the C files. My first attempt passed R CMD check, though there were no examples to exercise the code. When I tried to run it, it couldn't find the C routine. I had neglected to provide a .First.lib for my new library. When I corrected that, R cmd check failed with * checking generic/method consistency ... WARNING Error in .loadPackageQuietly(package, lib.loc) : Error in library(package, lib.loc = lib.loc, character.only = TRUE, verbose = FALSE) : .First.lib failed Execution halted * checking for assignment functions with final arg not named 'value' ... WARNING Error in .loadPackageQuietly(package, lib.loc) : Error in library(package, lib.loc = lib.loc, character.only = TRUE, verbose = FALSE) : .First.lib failed Execution halted * checking Rd files ... OK * checking for undocumented objects ... ERROR Error in .loadPackageQuietly(package, lib.loc) : 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). -- 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
On Wed, 29 Oct 2003, Ross Boylan wrote:> I am trying to package some code that is a tweak to the survival > package. When I asked earlier, the list consensus was that it would be > best to do this as a separate package, dependent on survival. > > This is proving a bit tricky. > > I have some run-time and compile time concerns. > > Run-time, my R code needs R code from survival, and my C code needs C > functions from survival. Will this all be properly loaded by, for > example, R CMD check, (assuming the proper dependency in DESCRIPTION) so > that it doesn't blow up?No. It is the responsibility of your package's .First.lib (etc) to load any other packages it requires. DESCRIPTION is used for installation, if at all. The answer would be a bit different if survival were in a namespace.> The reason I haven't just tried it is that the compile-time issues. My > C code depends on survival C code for headers. I believe that the > typical target system where the package would be installed won't have > these at all. Is that true? If so, what's the best way around this? > Maybe stick the headers in a subdirectory and mess with the build > options to include them? And hope they don't get out of sync with the > real ones?I think it is worse than that: there is no guarantee that your DLL will be able to see entry points in an already loaded DLL, as far as I know. The args for dyn.load(x, local = TRUE, now = TRUE) suggest that at least on some systems the entry points in survival.so are not shared (and you would need to alter survival's R code to change that). Now, you could try to link independently of R, but on MacOS X a shared module != a dynamic library, and on Windows and AIX you would need import libraries .... I would copy the parts of the survival C code you need into your own package. -- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
> From: Prof Brian Ripley [mailto:ripley at stats.ox.ac.uk] > > On Thu, 30 Oct 2003, Ross Boylan wrote:[...]> > Finally, a comment on R CMD check: perhaps it could produce > some more > > of the output when things fail? I found that to diagnose > the loading > > problems as I developed this, I had to attempt to load the package > > myself in R to see what the actual problem was. There > wasn't enough > > info in the R CMD check to tell what exactly the problem was. > > I think there usually is, but you have to look in the log > file or one of > the example files. > > But I would not be doing R CMD check until I had both installed and > loaded the package and run a few examples.I often do what Ross does, just because it's easy to do... Is it possible to get R to at least print the trackback on error when checking the package, so there's a bit more info in the log file? Best, Andy> -- > Brian D. Ripley, ripley at stats.ox.ac.uk > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UK Fax: +44 1865 272595 >
On Fri, 2003-10-31 at 06:41, A.J. Rossini wrote:> Ross Boylan <ross at biostat.ucsf.edu> writes: > > > > I also added library("survival") to my .First.lib. Is library, rather > > than require, the right choice here? I want it to fail if survival > > doesn't load. > > test the results from require, something like: > > if (!require("survival")) stop("can't load survival")Doesn't using library do about the same thing? What's the advantage of this, clearer diagnostics?