Re: [Rcpp-devel] Building shared libs with Rcpp does not work as before after Debian update ( function 'dataptr' not provided by package 'Rcpp' )
Hi,
I found the problem. The solution is as always: simple and stupid, and
difficult to find.
When using my shared library, I used to do this:
dyn.load(test.so)
.Call(test, x_ = 2, y_ = 3)
And got the error: function 'dataptr' not provided by package 'Rcpp'
I did not load the Rcpp library for that, because all the Rcpp routines
were already linked into my test.so!
The solution now is to do
require(Rcpp)
before. And everything works!
Maybe it is equally simple to include the boost libraries into R, to
improve the portability of my final package ...
All the best,
Andreas
On 18.03.2014 15:45, Andreas Recke wrote:
Hi,
maybe I can add some more details about my problem. It has been
addressed before at stackoverflow:
http://stackoverflow.com/questions/21657575/what-does-this-mean-in-lme4-function-dataptr-not-provided-by-package-rcpp
with the question:
I'm trying to do LMM using lme4, and this message pops up:
Error in initializePtr() : function 'dataptr' not provided by package 'Rcpp'
What should I do?
As proposed there in the responses, I reinstalled Rcpp, RcppArmadillo
and RcppEigen (in this order) from source packages.
However, when I look with nm into RcppEigen.so in the library folder, I
find the following:
andreas@persephone:~/R/x86_64-pc-linux-gnu-library/3.0/RcppEigen/libs$
nm RcppEigen.so | grep u
00238e70 u _ZGVZ13error_occuredvE3fun
00238e80 u _ZGVZ19reset_current_errorvE3fun
00238bb8 u _ZGVZ20rcpp_get_stack_tracevE3fun
00238bb0 u _ZGVZ20rcpp_set_stack_traceP7SEXPRECE3fun
00238e60 u _ZGVZ22rcpp_get_current_errorvE3fun
00238ba0 u _ZGVZ7dataptrP7SEXPRECE3fun
00238ba8 u _ZGVZ8demangleRKSsE3fun
00238e90 u _ZGVZN4Rcpp8internal18get_Rcpp_namespaceEvE3fun
00238e10 u _ZZ13error_occuredvE3fun
00238e30 u _ZZ19reset_current_errorvE3fun
00238b80 u _ZZ20rcpp_get_stack_tracevE3fun
00238b70 u _ZZ20rcpp_set_stack_traceP7SEXPRECE3fun
00238e00 u _ZZ22rcpp_get_current_errorvE3fun
00238b60 u _ZZ7dataptrP7SEXPRECE3fun -
here is the missing function
00238b90 u _ZZ8demangleRKSsE3fun
00238e20 u _ZZN4Rcpp8internal18get_Rcpp_namespaceEvE3fun
00238e40 u
_ZZN5Eigen8internal20manage_caching_sizesENS_6ActionEPlS2_E13m_l1CacheSize
00238e50 u
_ZZN5Eigen8internal20manage_caching_sizesENS_6ActionEPlS2_E13m_l2CacheSize
00033708 u
_ZZN5Eigen8internal23triangular_solve_vectorIddlLi1ELi1ELb0ELi0EE3runElPKdlPdE10PanelWidth
00033718 u
_ZZN5Eigen8internal23triangular_solve_vectorIddlLi1ELi2ELb0ELi0EE3runElPKdlPdE10PanelWidth
00033700 u
_ZZN5Eigen8internal23triangular_solve_vectorIddlLi1ELi2ELb0ELi1EE3runElPKdlPdE10PanelWidth
000336f8 u
_ZZN5Eigen8internal23triangular_solve_vectorIddlLi1ELi5ELb0ELi0EE3runElPKdlPdE10PanelWidth
000336f0 u
_ZZN5Eigen8internal23triangular_solve_vectorIddlLi1ELi6ELb0ELi1EE3runElPKdlPdE10PanelWidth
00033710 u
_ZZN5Eigen8internal32triangular_matrix_vector_productIlLi2EdLb0EdLb0ELi0ELi0EE3runEllPKdlS4_lPdlRS3_E10PanelWidth
This completely fits the above quoted error message. But I don't know
how to solve this. Can you help?
Best regards,
Andreas
On 18.03.2014 11:43, Andreas Recke wrote:
Hi,
until recently, I used a very simple mechanism to compile and link my
C++/Rcpp/RcppArmadillo code for using it in R.
Since the last update, however, something has changed with the linking,
and the Rcpp shared library is not linked to
the final libary as before.
My question is, whether I need to change the my code to take these
changes into account? Is there a compatibility problem
with earlier versions of R and Rcpp?
I would like to have at least the option to use the command line to
compile my code and to have it working even with different
versions of R and Rcpp, especially because I found a way to use the
THRUST library for parallel computing with Rcpp, Boost and R.
So here is my problem:
*** test.cpp ***
#include iostream
#include iomanip
#include cmath
#include RcppArmadillo.h
using namespace Rcpp;
double norm(double x, double y)
{
return sqrt(x*x + y*y);
}
RcppExport SEXP norm_wrapper(SEXP x_,SEXP y_)
{
// step 0: convert input to C++ types
double x = asdouble(x_), y= asdouble(y_);
// step 1: call the underlying C ++ function
double res = norm (x,y);
// step 2: return the result as a SEXP
return wrap(res);
}
***
*** my makevars
PKG_CXXFLAGS=$(shell Rscript -e Rcpp:::CxxFlags()) $(shell Rscript -e
RcppArmadillo:::CxxFlags())
PKG_LIBS=$(shell Rscript -e Rcpp:::LdFlags()) $(LAPACK_LIBS) $(BLAS_LIBS)
$(FLIBS) -lboost_system -lboost_thread
* in bash, I compile with ***
R CMD SHLIB test.cpp
Re: [Rcpp-devel] Building shared libs with Rcpp does not work as before after Debian update ( function 'dataptr' not provided by package 'Rcpp' )
On 19 March 2014 at 13:32, Andreas Recke wrote: | I found the problem. Very good :) And thanks for reporting back here. | The solution is as always: simple and stupid, and difficult to find. | When using my shared library, I used to do this: | dyn.load(test.so) | .Call(test, x_ = 2, y_ = 3) | And got the error: function 'dataptr' not provided by package 'Rcpp' Well I think I suggested three times not to do that dyn.load / .Call dance. We had inline for four or so years which already does it for you. We then added sourceCpp() etc which is even easier. Please use Rcpp Attributes (or at least cxxfunction()). Friends don't let friends use dyn.load() anymore. | I did not load the Rcpp library for that, because all the Rcpp routines | were already linked into my test.so! | The solution now is to do | require(Rcpp) | before. And everything works! That will deal with the Rcpp instantiation. All this will also be taken care of when you write a package ... | Maybe it is equally simple to include the boost libraries into R, to | improve the portability of my final package ... ... which will deal with this. Boost in templates-only mode is taken care of by the BH package. All you need there is a LinkingTo: BH in addition to Rcpp. But you seem to be linking with Boost System and Boost Thread. At a package level that is pretty easy (via configure and/or environment variables) and I guess I should write up something for the Rcpp Gallery on how I'd do it on the fly: either via PKG_LIBS as I mentioned in the thread or possibly via an on-the-fly plugin. Dirk | | All the best, | Andreas | | | | | | | On 18.03.2014 15:45, Andreas Recke wrote: | Hi, | | maybe I can add some more details about my problem. It has been | addressed before at stackoverflow: | | http://stackoverflow.com/questions/21657575/what-does-this-mean-in-lme4-function-dataptr-not-provided-by-package-rcpp | | with the question: | I'm trying to do LMM using lme4, and this message pops up: | | Error in initializePtr() : function 'dataptr' not provided by package 'Rcpp' | | What should I do? | | As proposed there in the responses, I reinstalled Rcpp, RcppArmadillo | and RcppEigen (in this order) from source packages. | However, when I look with nm into RcppEigen.so in the library folder, I | find the following: | | andreas@persephone:~/R/x86_64-pc-linux-gnu-library/3.0/RcppEigen/libs$ | nm RcppEigen.so | grep u | | | | | 00238e70 u _ZGVZ13error_occuredvE3fun | 00238e80 u _ZGVZ19reset_current_errorvE3fun | 00238bb8 u _ZGVZ20rcpp_get_stack_tracevE3fun | 00238bb0 u _ZGVZ20rcpp_set_stack_traceP7SEXPRECE3fun | 00238e60 u _ZGVZ22rcpp_get_current_errorvE3fun | 00238ba0 u _ZGVZ7dataptrP7SEXPRECE3fun | 00238ba8 u _ZGVZ8demangleRKSsE3fun | 00238e90 u _ZGVZN4Rcpp8internal18get_Rcpp_namespaceEvE3fun | 00238e10 u _ZZ13error_occuredvE3fun | 00238e30 u _ZZ19reset_current_errorvE3fun | 00238b80 u _ZZ20rcpp_get_stack_tracevE3fun | 00238b70 u _ZZ20rcpp_set_stack_traceP7SEXPRECE3fun | 00238e00 u _ZZ22rcpp_get_current_errorvE3fun | 00238b60 u _ZZ7dataptrP7SEXPRECE3fun - | here is the missing function | 00238b90 u _ZZ8demangleRKSsE3fun | 00238e20 u _ZZN4Rcpp8internal18get_Rcpp_namespaceEvE3fun | 00238e40 u | _ZZN5Eigen8internal20manage_caching_sizesENS_6ActionEPlS2_E13m_l1CacheSize | 00238e50 u | _ZZN5Eigen8internal20manage_caching_sizesENS_6ActionEPlS2_E13m_l2CacheSize | 00033708 u | _ZZN5Eigen8internal23triangular_solve_vectorIddlLi1ELi1ELb0ELi0EE3runElPKdlPdE10PanelWidth | 00033718 u | _ZZN5Eigen8internal23triangular_solve_vectorIddlLi1ELi2ELb0ELi0EE3runElPKdlPdE10PanelWidth | 00033700 u | _ZZN5Eigen8internal23triangular_solve_vectorIddlLi1ELi2ELb0ELi1EE3runElPKdlPdE10PanelWidth | 000336f8 u | _ZZN5Eigen8internal23triangular_solve_vectorIddlLi1ELi5ELb0ELi0EE3runElPKdlPdE10PanelWidth | 000336f0 u | _ZZN5Eigen8internal23triangular_solve_vectorIddlLi1ELi6ELb0ELi1EE3runElPKdlPdE10PanelWidth | 00033710 u | _ZZN5Eigen8internal32triangular_matrix_vector_productIlLi2EdLb0EdLb0ELi0ELi0EE3runEllPKdlS4_lPdlRS3_E10PanelWidth | | | This completely fits the above quoted error message. But I don't know | how to solve this. Can you help? | | Best regards, | Andreas | | | | | | | | On 18.03.2014 11:43, Andreas Recke wrote: | Hi, | | until recently, I used a very simple mechanism to compile and link my | C++/Rcpp/RcppArmadillo code for using it in R. | Since the last update, however, something has changed with the linking, | and the Rcpp shared library is not linked to | the final libary as before. | My question is, whether I need to change the my code to take these | changes into account? Is there a compatibility problem | with earlier versions of R and Rcpp? | I
