Rcpp on Leopard
On Apr 13, 2009, at 13:53 , Jonathan Terhorst wrote:
I just finished building a C++ extension using Rcpp on Mac OS X and have a couple tips for anyone trying to do the same. I used RcppTemplate as a starting point. When developing and testing, it was easier to compile the extension by hand and use dyn.load() as opposed to using the R packaging mechanism to rebuild the entire package every time. In compiling RcppTemplate I ran into the following difficulties on Mac OS X 10.5:
I think RcppTemplate is long deprecated and was replaced entirely by Rcpp if I remember correctly. The latter was updated no so long ago to work with OS X.
- ./configure is broken due to some missing environment vars. Use "R_ARCH="/`arch`" R_SHARE_DIR=$R_HOME/share ./configure" instead.
That is wrong! The configure is supposed to be run from the R environment which is where those variables come from. If you want to run it by hand, use the proper R CMD ./configure instead.
- Marking a function RcppExport will cause the compile to fail because __declspec(dllexport) is Windows-specific and not recognized by the Apple compiler. Change the lines in Rcpp.hpp from
I suspect you have some old version - this problem does not exist in the current version...
#ifdef BUILDING_DLL #define RcppExport extern "C" __declspec(dllexport) #else #define RcppExport extern "C" #endif to #if BUILDING_DLL && WIN32 #define RcppExport extern "C" __declspec(dllexport) #else #define RcppExport extern "C" #endif or if you don't care about cross-platform just write #define RcppExport extern "C" - Loading your compiled DLL using dyn.load() will complain about not being able to find libRcpp. I think this is due to an improper path-name being embedded in the library when it is compiled on your machine. $ otool -L /Library/Frameworks/R.framework/Resources/library/Rcpp/lib/ i386/libRcpp.dylib /Library/Frameworks/R.framework/Resources/library/Rcpp/lib/i386/ libRcpp.dylib: /Builds/Rdev-web/QA/Simon/packages/tiger-universal/Rlib/2.8/Rcpp/lib/ i386/libRcpp.dylib (compatibility version 0.0.0, current version 0.0.0) For now you can fix this in your .dll using install_name_tool -- see http://qin.laya.com/tech_coding_help/dylib_linking.html for a good description of what needs to be done. A better solution would be for the package maintainer to change the build process so this gets generated correctly.
Not really, the build process is correct. If you compile Rcpp from sources you'll have the correct path for your target destination. Apparently you didn't do that. When you install Rcpp from a binary distribution, it cannot know where you are installing (binary installation simply unpacks the tar ball) it so it has no way of knowing the correct path. However, even if you use the pre-compiled binary, you can use the static version of the library which doesn't have path issues. Second, you can fix the path in the installed dylib binary - let's say you installed Rcpp in $HOME/ Library/R/2.8/library/Rcpp then you can run install_name_tool -id $HOME/Library/R/2.8/library/Rcpp/lib/i386/ libRcpp.dylib $HOME/Library/R/2.8/library/Rcpp/lib/i386/libRcpp.dylib (replace i386 by x86_64 for 64-bit or ppc for PowerPC).
After I had the extension written and functioning properly, I used package.skeleton to generate a tree, and then copied all of the source files in the /src directory (including Rcpp.cpp and Rcpp.hpp) and generated the proper firstlib.R file to load in my functions. After this things went smoothly--'R CMD build' correctly compiled all of the source files into a shared object file and I was able to build and install the package with no further modifications. It took me a little while to figure all of this out, so I figured I'd post it to hopefully save someone else the time.
You may have asked and saved yourself a lot of time ;). Cheers, Simon