Подтвердить что ты не робот

R CMD check note: не найдено вызовов: "R_registerRoutines", R_useDynamicSymbols

Как избежать следующего ПРИМЕЧАНИЕ, которое появляется в R CMD check с новой версией разработки R (R В разработке (нестабильно) (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.

Например, в Hmisc

4b9b3361

ОТВЕТЫ

Ответ 1

Сообщение несколько тайное. Я осмотрел и другие пакеты, и обнаружил, что useDynLib(packagename) в файле NAMESPACE был заменен на useDynLib(packagename, .registration = TRUE).

Кроме того, я добавил файл .c с именем registerDynamicSymbol в каталог src/ со следующим кодом:

// 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);
}

Я принял это предложение от GitHub Rcpp. Каноническая ссылка находится в Написание R Расширений

Также R Devel Mailinglist предоставил дополнительную информацию.

UPDATE

Самый прямой прямолинейный подход:

  • используйте текущую версию разработки R (которая в конечном итоге станет 3.4)
  • Запустите tools::package_native_routine_registration_skeleton(".") и скопируйте и вставьте полный вывод в файл packagename_init.c, который будет помещен в src/
  • update NAMESPACE, подтверждая, что useDynLib(packagename, .registration = TRUE)
  • При необходимости замените exportPattern на export( list of object to be exported )

ОБНОВЛЕНИЕ 18 июля

Как отмечено @Symbolix с использованием самой последней версии R и RStudio devtools, точка 2. (файлы init.c) появляется с помощью devthools (с использованием контрольной цифры RStudio) или пакетов инструментов.

Ответ 2

Я столкнулся с постоянной проблемой с пакетом сборки Windows. (.dll вместо .so)

Принятый ответ выше также должен решить эту проблему для Windows, но если он не разрешит ее. Убедитесь, что objdump.exe указывает соответствующую арку. т.е. .../Mingw_64/bin/objdump.exe. Это можно проверить из командной строки с помощью which objdump.exe. Как-то 32-разрядный objdump.exe нашел свой путь в более высокий приоритет на моем пути. Это несоответствие будет выдавать ошибку File format not recognized.