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

How to avoid the following NOTE that is appearing in R CMD check with the new R development version ( R Under development (unstable) (2017-02-15 r72179))?

• checking for unstated dependencies in examples ... OK
• checking line endings in C/C++/Fortran sources/headers ... OK
• checking compiled code ... NOTE
File ‘pkgname/libs/pkgname.so’:
  Found no calls to: ‘R_registerRoutines’, ‘R_useDynamicSymbols’

It is good practice to register native routines and to disable symbol
search.

For example in Hmisc

Solution 1:

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.

Solution 2:

I ran into a persistent issue with a Windows build package. (.dll instead of .so)

The accepted answer above should also resolve this issue for Windows, but if it does not resolve it. Make sure that objdump.exe is pointing the appropriate arch. i.e. .../Mingw_64/bin/objdump.exe. This can be checked from a command prompt with which objdump.exe. Somehow a 32-bit objdump.exe found its way into a higher priority position in my path. This arch mismatch will produce a File format not recognized error.