R note de vérification CMD: aucun appel trouvé à: ‘R_registerRoutines’, ‘R_useDynamicSymbols’

Comment éviter la remarque suivante qui apparaît dans la R CMD check avec la nouvelle version de développement R (R en développement (instable) (2017-02-15 r72179))?

 • checking for unstated dependencies in examples ... OK • checking line endings in C/C++/Fortran sources/headers ... OK • checking comstackd 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. 

Par exemple dans Hmisc

Le message est un peu mystérieux. J’ai aussi regardé autour des autres paquets et j’ai trouvé que useDynLib(packagename) dans le fichier NAMESPACE était remplacé par useDynLib(packagename, .registration = TRUE) .

En outre, j’ai ajouté un fichier .c , nommé registerDynamicSymbol dans le répertoire src/ avec le code suivant:

 // RegisteringDynamic Symbols #include  #include  #include  void R_init_markovchain(DllInfo* info) { R_registerRoutines(info, NULL, NULL, NULL, NULL); R_useDynamicSymbols(info, TRUE); } 

J’ai pris cette suggestion de GitHub Rcpp . La référence canonique est dans Writing R Extensions

Aussi R Devel Mailinglist a fourni des informations supplémentaires.

METTRE À JOUR

L’approche directe la plus directe est la suivante:

  1. utiliser la version de développement R actuelle (qui deviendra éventuellement 3.4)
  2. Exécutez les tools::package_native_routine_registration_skeleton(".") Et copiez et collez la sortie complète dans un fichier packagename_init.c à placer dans src/
  3. mettre à jour NAMESPACE , en vérifiant que useDynLib(packagename, .registration = TRUE)
  4. Si nécessaire, remplacez exportPattern par export( list of object to be exported )

MISE À JOUR 18 juillet

Comme indiqué par @Symbolix en utilisant la version la plus récente de devtools de R et RStudio, le point 2. (fichiers init.c) apparaît géré par devtools (à l’aide du chiffre de contrôle de RStudio) ou par des packages d’outils.

J’ai rencontré un problème persistant avec un package de compilation Windows. (.dll à la place de .so)

La réponse acceptée ci-dessus devrait également résoudre ce problème pour Windows, mais si elle ne le résout pas. Assurez-vous que objdump.exe pointe l’arc approprié. Par exemple .../Mingw_64/bin/objdump.exe . Cela peut être vérifié à partir d’une invite de commande avec which objdump.exe . objdump.exe 32 bits objdump.exe retrouvé dans une position prioritaire dans mon chemin. Cette incompatibilité d’archive produira une erreur de File format not recognized .