[Rcpp-devel] Bizarre Rcpp::XPtr problem on GCC
Kevin Thornton
krthornt at uci.edu
Thu May 21 18:36:07 CEST 2015
Dirk,
OK, I’ll try again. I’ll respond out of order:
c) There are no run instructions. This issue (as stated in all of my posts on this issue) is that GCC will not load the .so from the MWE because standard_delete_finalizer is missing. Compiling with clang++ does not have this issue, which brings us to…
a) Again, the issue here is GCC vs clang, and [[Rcpp::plugins(“cpp11”)]] (and CXX_STD = CXX11 in a Makevars.in) have an unfortunate side-effect on all the Linux (Ubuntu) systems that I use. They over-ride the definition of CXX in ~/.R/Makevars, which means I can only use GCC. I’m assuming that this is an R issue, but it is important to reproducing this example, which is the raison d’etre for the R scripts in the gist…
For example, here is my ~/.R/Makevars:
cat ~/.R/Makevars
CXX=ZeppelinRules
Now, let’s see what happens with Rcpp::plugins(“cpp11”):
Rscript -e 'library(Rcpp)' -e 'sourceCpp(code="// [[Rcpp::plugins(\"cpp11\")]]\n// [[Rcpp::export]]\nvoid foo(){}",verbose=TRUE)'
The relevant output is:
g++ -std=c++11 -I/usr/share/R/include -DNDEBUG -I"/usr/local/lib/R/site-library/Rcpp/include" -I"/tmp/Rtmpqaq1Pj" -fpic -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -g -c file52eccfd254e.cpp -o file52eccfd254e.o
g++ -std=c++11 -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions -Wl,-z,relro -o sourceCpp_61207.so file52eccfd254e.o -L/usr/lib/R/lib -lR
So, the plugin over-rides my Makevars, and without it we learn that Zeppelin is not a C++ compiler:
Rscript -e 'library(Rcpp)' -e 'sourceCpp(code="// [[Rcpp::export]]\nvoid foo(){}",verbose=TRUE)’
The relevant output is:
ZeppelinRules -I/usr/share/R/include -DNDEBUG -I"/usr/local/lib/R/site-library/Rcpp/include" -I"/tmp/Rtmpblhfp9" -fpic -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -g -c file530e5ce6ddd1.cpp -o file530e5ce6ddd1.o
/bin/bash: ZeppelinRules: command not found
So, my original gist was correct, because it is a MWE, and sets the cpp11 properly, in the sense that it allows me to properly select my c++ compiler via ~/.R/Makevars and avoids the side-effect described above:
Sys.setenv("PKG_CXXFLAGS" = "-std=c++11”)
Finally, here’s an all-in 1 response to:
b.) build instructions
VERSION1
This gives the following error using all combos of G++ 4.7,4.8,4.9 and Rcpp 0.11.4 through 0.11.6 on several different Linux systems (Ubuntu servers, mostly 14.04, and our HPC system which is some custom distro…):
Error in dyn.load("/tmp/RtmpoMjBFt/sourcecpp_53761e3a356a/sourceCpp_4629.so") :
unable to load shared object '/tmp/RtmpoMjBFt/sourcecpp_53761e3a356a/sourceCpp_4629.so':
/tmp/RtmpoMjBFt/sourcecpp_53761e3a356a/sourceCpp_4629.so: undefined symbol: _ZN4Rcpp25standard_delete_finalizerISt5tupleIIiiEEEEvPT_
Calls: sourceCpp -> source -> withVisible -> eval -> eval -> dyn.load
(With clang++, all is cool, but you need to change your CXX yourself to see that, so edit your own ~/.R/Makevars, and don’t use Rcpp::plugins, at least on Ubuntu…)
The code is:
library(Rcpp)
Sys.setenv("PKG_CXXFLAGS" = "-std=c++11")
sourceCpp(code="#include <Rcpp.h>
#include <tuple>
#ifdef USE_DELETER
namespace Rcpp {
template<>
inline void standard_delete_finalizer<std::tuple<int,int> >( std::tuple<int,int> * t ) { delete t; }
}
#endif
namespace foo {
using tuple_t = std::tuple<int,int>;
template<typename T>
SEXP foofunc(const T & a)
{
return Rcpp::XPtr<tuple_t>(new tuple_t(a,a));
}
}
// [[Rcpp::export()]]
SEXP foofunc_caller(const int & a) { return foo::foofunc(a); }",
verbose = TRUE)
VERSION 2:
We define USE_DELETER, and everything works with GCC:
library(Rcpp)
Sys.setenv("PKG_CXXFLAGS" = "-std=c++11 -DUSE_DELETER")
sourceCpp(code="#include <Rcpp.h>
#include <tuple>
#ifdef USE_DELETER
namespace Rcpp {
template<>
inline void standard_delete_finalizer<std::tuple<int,int> >( std::tuple<int,int> * t ) { delete t; }
}
#endif
namespace foo {
using tuple_t = std::tuple<int,int>;
template<typename T>
SEXP foofunc(const T & a)
{
return Rcpp::XPtr<tuple_t>(new tuple_t(a,a));
}
}
// [[Rcpp::export()]]
SEXP foofunc_caller(const int & a) { return foo::foofunc(a); }",
verbose = TRUE)
The output from gcc 4.9 on my system is:
/usr/lib/R/bin/R CMD SHLIB -o 'sourceCpp_25020.so' 'file53a24f1a73a8.cpp'
g++ -I/usr/share/R/include -DNDEBUG -I"/usr/local/lib/R/site-library/Rcpp/include" -I"/tmp/RtmphmQ6cd" -std=c++11 -DUSE_DELETER -fpic -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -g -c file53a24f1a73a8.cpp -o file53a24f1a73a8.o
g++ -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions -Wl,-z,relro -o sourceCpp_25020.so file53a24f1a73a8.o -L/usr/lib/R/lib -lR
—Kevin
> On May 20, 2015, at 6:27 PM, Dirk Eddelbuettel <edd at debian.org> wrote:
>
>
> Kevin,
>
> Still not a minimally reproducible example as it lacks
>
> a) instructions to tell sourceCpp() to turn on C++11 (ie
>
> // [[Rcpp::plugins("cpp11")]]
>
> b) build instructions
>
> c) run instructions
>
> We are a fairly common standard for this over here, or on SO.
>
> Good examples are provided by the Rcpp Gallery which, when sourced by
> Rcpp::sourceCpp(), also runs included R code.
>
> If you want help from the readers of this list, help them help you by
> reproducible example. Nobody has time to figure out what you may have
> meant. Make it explicit.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
More information about the Rcpp-devel
mailing list