On Sun, 28 Jun 2020 12:43:53 +0200
Lisa GM <lisainconnecti...@gmail.com> wrote:
> "sum_c" not resolved from current namespace (sum)
As mentioned by Dirk Eddelbuettel, this is not the way R packages are
supposed to be built [*], but if you are absolutely positive you cannot
build the DLL from source together with the package or link your
package to externally installed DLL (as done by packages curl, rgdal,
and many others), it still seems to be possible. I have been able to
get a dummy package to work like this:
.onLoad <- function(libname, pkgname)
library.dynam('dynl', pkgname, libname, TRUE)
.onUnload <- function(libpath)
library.dynam.unload('dynl', libpath)
do <- function()
.C('do_hello', x = as.integer(1L), y = as.numeric(2), PACKAGE = 'dynl')
(Note the extra PACKAGE argument required in absence of native routine
registration or useDynLib(...) declarations in NAMESPACE)
I placed the DLL itself in file.path('inst', 'libs',
paste0('dynl', .Platform$dynlib.ext)) under the package source
directory and made sure that it exports a C function
void do_hello(int * x, double * y).
Needless to say, this goes against CRAN and Bioconductor policies. The
preferred approach is described in Writing R Extensions, section 1.2.
--
Best regards,
Ivan
[*] See <https://cran.r-project.org/doc/manuals/R-exts.html> sections
1.5.4 and 5.4 for preparing C functions to be called from an R package.
The Rcpp package does wrap all this in a very convenient way, see the
Rcpp.package.skeleton function.
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
