I submitted my package to the CRAN repository. The package was accepted without errors but in the second step of checking the CRAN maintainers reported the following error.
Unfortunately I don't understand how I can fix it.
In file included from /Builds/CRAN-QA-Simon/packages/mavericks-x86_64/Rlib/3.3/RcppArmadillo/include/armadillo:23:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/fstream:864:20: error:
no member named 'Rf_error' in 'std::__1::codecvt_base'; did you mean simply 'Rf_error'?
if (__r == codecvt_base::error)
^~~~~~~~~~~~~~
/Library/Frameworks/R.framework/Resources/include/R_ext/Error.h:35:12: note:
'Rf_error' declared here
void NORET Rf_error(const char *, ...);
^
In my C++ file, I wrote:
#include <math.h>
#include "ANN/ANN.h"
#include "NN.h"
#include <R.h>
#include "RcppArmadillo.h"
#include <map>
#include <vector>
#include <iostream>
How do I have to correct this? Has Rpp.h to be included?
R itself is written in C, due to its early start way back in the early 1990s. C has no namespaces -- which can lead to conflicts as we lack the namespace separation. Identifiers from different libraries sharing the same name can be mistaken. This has happened here.
R uses, in its C API, functions length(), error(), .... etc which, given how common the name is, are likely to clash. So R has as mechanism of prepending Rf_ to its symbols: error becomes Rf_error. This use the preprecessor, which is reasonably dumb (as opposed to using the compiler itself). So when R sees error it wants it to be Rf_error.
What happens here is that you very likely has #include <RcppArmadillo.h> (and therefore the implicit #include <Rcpp.h> before the include for your actual library. Try it the other way around. That way R's messing with its error() will not interfere with the library one which is confusing you here.
Related
Can I stop it?
That requires to add RcppArmadillo to Imports, when otherwise LinkingTo would be enough.
Does this already trigger Roxygen to do this?
#include "RcppArmadillo.h"
// [[Rcpp::depends(RcppArmadillo)]]
#include <cmath>
#include <math.h>
#include <Rcpp.h>
// [[Rcpp::plugins("cpp17")]]
// [[Rcpp::export]]
double rcpp_hello_world(Rcpp::NumericVector x) {
double z;
z = std::cyl_bessel_i(0, x[0]);
return z ;
}
When I run the above code and call it using sourceCpp, it works as expected. However inside a R package setup I get
error: cyl_bessel_iis not a member of ‘std
11 | z = std::cyl_bessel_i[0]);
| ^~~~~~~~~~~~
make: *** [/usr/lib64/R/etc/Makeconf:177: rcpp_hello_world.o] Error 1
ERROR: compilation failed for package ‘Package’
upon running Rcpp::compileAttributes() and devtools::document(). I initialised the package with Rcpp.package.skeleton.
cyl_bessel_i was added to the standard library in C++17.
I am using gcc-12.1.0-2 and R-4.2.0-3. I am on Arch Linux.
The default C++ standard used in current versions of R is C++11 (or C++14 if available). Since you require C++17, you need to declare it in the src/Makevars file, using the line
CXX_STD=CXX17
In a comment you referred to the Rcpp documentation which says that Makevars is optional since Rcpp 0.11.0. I think that was written about linking to the Rcpp libs, but it is also true here, as pointed out by #MikkoMarttila: you can alternatively declare the C++ version in the SystemRequirements: field of the DESCRIPTION file, e.g.
SystemRequirements: C++17
To use RcppArmadillo, we're often instructed to have the following lines at the top:
#include <RcppArmadillo.h>
// [[Rcpp::depends(RcppArmadillo)]]
Why do we need both? Isn't the #include directive sufficient for us to have access to all functions defined inside the scope of RcppArmadillo?
There are two different things at play:
The compiler needs the header RcppArmadillo.h in order to know about types from (Rcpp)Armadillo, Rcpp (as this one pulls in Rcpp.h as well) and therefore R. I presume you know you need this. But ...
How would R know to add the -I... flag required for this? It wouldn't!
At a package level the LinkingTo: helps for the header case. But in deeper sense sometimes we need headers and linking (ie RcppGSL) and in that case, the hook we have here via Rcpp::depends into Rcpp Attributes ensures we can do this.
So the // [[Rcpp::depends(RcppArmadillo)]] helps for sourceCpp() use. It is not needed in a package. "Plugins" like this are discussed a little in the Rcpp Attributes vignette.
I am trying to reimplement an R function using C++ and RCpp to speed up the computation. And in the C++ implementation, I need to use a Fortran function mvtdst found in link.
#include <Rcpp.h>
#include "mvtnorm.h"
using namespace Rcpp;
// [[Rcpp::export]]
NumericVector pmvnorm_rcpp(NumericVector upper, NumericMatrix corr)
{
double error;
double mvnP = pmvnorm_P(2, upper, corr, &error) ;
return mvnP ;
}
/*** R
pmvnorm_rcpp(c(1.5,1.5),c(0.0))
*/
Here, pmvnorm_P is defined in the mvtnorm.cpp file.
All the files found in link are kept in the working directory along with the RcppWrapper.cpp file.
When I compile my RcppWrapper.cpp file using sourceCpp() function in RCpp package, it gives the following error.
mvtnorm.o:mvtnorm.cpp:(.text+0x7c): undefined reference to `mvtdst_'
collect2.exe: error: ld returned 1 exit status
Error in Rcpp::sourceCpp("RcppWrapper.cpp") :
Error occurred building shared library.
Does anyone know how to resolve this error?
When you have code in two sources files
mvtnorm.cpp calling your backend function pmvnorm_P()
another file providing it
then you also must provide link instructions. Simply put, sourceCpp() is only intentended and working for one-file solutions (unless you give link instructions).
Simplest fix: just create a package assembling all your files in src/.
Fortran and C++ mangle the names of functions differently. It looks like mvtdst is the name of your Fotran function. (Right?) You need to "mangle" that by hand when called from C++. So instead of calling mvtdst, call mvtdst_ with the trailing underscore.
Unfortunately, compilers are not consistent in the mangling, so this will not be portable. (To make it portable, you'll need some sort of preprocessing that matched the mangling to the compiler.)
I got some code for using OpenGL in Qt. And when I run it I got error as below:
C:\Users\Administrator\Desktop\NeHe6\NeHe6-build-desktop-Qt_4_8_1_for_Desktop_-_MinGW__Qt_SDK__Debug\..\NeHe6\nehewidget.cpp:54: error: 'gluLookAt' was not declared in this scope
It seems the header is missing. And the current headers are:
#include "nehewidget.h"
#include <QtGui>
#include <qtopengl\QtOpenGL>
And "nehewidget.h" contains below headers:
#include <qtopengl\QGLWidget>
#include <QTimer>
Could anyone tell me what is the missing header?
It looks like it cant find the libraries you need. Check your installation of the openGL helper libraries. Specifically it is looking for GLU. You need to add it to your linker options, for example -lGLU. You then need to include it your code:
#include <GL/glu.h>
Examples of linking and including GLU (and GLUT) across multiple platforms can be found here
Add this line at the end of the .pro file and you add the lib to your project:
LIBS += -L/usr/local/lib -lGLU