R Cmd Check Note: Found No Calls To: 'R_Registerroutines', 'R_Usedynamicsymbols'

R CMD check note: Found no calls to: ‘R_registerRoutines’, ‘R_useDynamicSymbols’

The message is somewhat arcane. I looked around also in other packages and I found that the useDynLib(packagename) in the NAMESPACE file was replaced by useDynLib(packagename, .registration = TRUE).

In addition, I added a .c file, named registerDynamicSymbol in the src/ directory with the following code:

// RegisteringDynamic Symbols

#include <R.h>
#include <Rinternals.h>
#include <R_ext/Rdynload.h>

void R_init_markovchain(DllInfo* info) {
  R_registerRoutines(info, NULL, NULL, NULL, NULL);
  R_useDynamicSymbols(info, TRUE);
}

I took this suggestion from GitHub Rcpp. The canonical reference is in Writing R Extensions

Also R Devel Mailinglist provided supplementary infos.

UPDATE

The most direct straightforward approach is:

1. use the current R Development Version (that will eventually become 3.4)
2. Run the tools::package_native_routine_registration_skeleton(".") and copy and paste the full output in a packagename_init.c file to be put in src/
3. update NAMESPACE, verifying that useDynLib(packagename, .registration = TRUE)
4. If necessary, replace the exportPattern with export( list of object to be exported )

UPDATE 18th July

As noted by @Symbolix using the most recent version of R and RStudio's devtools the point 2. (init.c files) appears handled by either devtools (using RStudio check digit) or tools packages.

Fortran code and Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols'

I solved the problem and you may find it useful for your own case.
Let's assume you have a subroutine called myf.f90 in src directory with following content:

    SUBROUTINE cf(r,cd,loci)
    INTEGER::r,cd
    DOUBLE PRECISION::loci
....
....
....
    END SUBROUTINE cf

To register this you need to do the following :

A) Run tools::package_native_routine_registration_skeleton("package directory")

B) Edit the output; for the example above would be:

#include <R.h>
#include <Rinternals.h>
#include <stdlib.h> // for NULL
#include <R_ext/Rdynload.h>

/* FIXME:
Check these declarations against the C/Fortran source code.
*/

/* .Fortran calls */
extern void F77_NAME(cf)(int *r, int *cd, double *loci);

static const R_FortranMethodDef FortranEntries[] = {
  {"cf", (DL_FUNC) &F77_NAME(cf),  3},
  {NULL, NULL, 0}
};

void R_init_packagename(DllInfo *dll)
{
  R_registerRoutines(dll, NULL, NULL, FortranEntries, NULL);
  R_useDynamicSymbols(dll, FALSE);
}

C) Copy and paste the full output in a packagename_init.c file to be put in src/

D) Update NAMESPACE, verifying that useDynLib(packagename, .registration = TRUE)

function leading to check error in automatically generated RcppExports.R

Congratulations, you've experienced the Section 5.4: Registering native routines requirement added in R 3.4.0. The requirement mandated the inclusion of a src/init.c file that registered each C++ function and their parameters. Thus, Rcpp 0.12.11 generates this file inside of the RcppExports.cpp. Meanwhile, the RcppExports.R file, which is what this question is based upon, has its context being dependent on whether the user appropriately sets useDynLib(pkgname, .registration=TRUE) or useDynLib(pkgname), where the later is not ideal as it does not take advantage of a new option introduced in Rcpp 0.12.11 discussed next.

As a result of this shift in CRAN policy, JJ Allaire, the creator of Attributes for Rcpp ¹, was inspired to advance a suggestion made by Douglas Bates back in 2012 when attributes was first added. Specifically, the goal was to change the call from being string-based to being a symbol. The rationale behind the change is simply put that a symbol is onhand when the package loads vs. a string which has to be looked up and converted into a symbol each time the function is run. Therefore, symbol lookup is less expensive on repetitive calls when compared to the string based method of Rcpp in the past.

Basically, this line:

.Call('RGraphM_run_graph_match', PACKAGE = 'RGraphM', A, B, algorithm_params)

Involved R looking up the symbol on each call of the encompassing R function to access the C++ function.

Meanwhile, this line:

.Call(RGraphM_run_graph_match, A, B, algorithm_params)

is a direct call to the C++ function as the symbol is already in memory.

And those are primarily the reasons behind why Rcpp changed how RcppExports.R was automatically generated. One of the downside of this approach is the inability to globally export all functions like before. In particular, some users that had in their NAMESPACE file a global symbol export statement e.g.

exportPattern("^[[:alpha:]]+")

had to remove it and opt to manually specify what functions or variables should be exported.

For more details, you may wish to see the GitHub PR that introduced this feature:

https://github.com/RcppCore/Rcpp/pull/694

---

1: For more on Attributes, see my history post: http://thecoatlessprofessor.com/programming/rcpp/to-rcpp-attributes-and-beyond-from-inline/

rlang::expr(`=`(!!rlang::ensym(x), !!rlang::as_name(y))) causes weird note in devtools::check()

The CRAN checks don't really like non-standard evaluation so when it sees you calling the = function which it interprets as the <- function, it doesn't like it.

The rlang package gets around this by defining the := operator when you are trying to dynamically build named parameters. So instead you can build your arguments with

args <- rlang::exprs(!!rlang::as_name(x) := !!y)

And then inject them into the call with

rlang::expr(foo(!!!args))
# foo(a = "b")

That should prevent CRAN from trying to find the special assignment operator and is generally how one should use rlang for such a purpose.

---

Related Topics