@@ -1684,4 +1684,29 @@ sort(x)
16841684rcpp_sort(x)
16851685```
16861686
1687+ ## Package building fails with 'symbols not found'
1688+
1689+ R 3.4.0 and later strongly encourage registering dynamically loadable
1690+ symbols. In the stronger form (where ` .registration=TRUE ` is added to the
1691+ ` useDynLib() ` statement in ` NAMESPACE ` ), only registered symbols can be
1692+ loaded. This is fully supported by Rcpp 0.12.12 and later, and the required code
1693+ is added to ` src/RcppExports.cpp ` .
1694+
1695+ However, the transition from the previously generated file ` src/RcppExports.cpp `
1696+ to the new one may require running ` compileAttributes() ` twice (which does not
1697+ happen when, _ e.g., devrtools is used). When ` Rcpp::compileAttributes() ` is
1698+ called, it also calls ` tools::package_native_routine_registration_skeleton() ` ,
1699+ which crawls through usages of ` .Call() ` in the ` R/ ` source files of the package to
1700+ figure out what routines need to be registered. If an older ` RcppExports.R ` file
1701+ is discovered, its out-of-date symbol names get picked up, and registration
1702+ rules for those symbols get written as well. This will register more symbols for
1703+ the package than are actually defined, leading to an error. This point has been
1704+ discussed at some length both in the GitHub issue tickes, on StackOverflow and
1705+ elsewhere.
1706+
1707+ So if your autogenerated file fails, and a ` symbols not found ` error is reported
1708+ by the linker, consider running ` compileAttributes() ` twice. Deleting
1709+ ` R/RcppExports.R ` and ` src/RcppExports.cpp ` may also work.
1710+
1711+
16871712\newpage
0 commit comments