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 <e...@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 | e...@debian.org
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
