[R-SIG-Mac] Rcpp on Leopard

[Simon Urbanek]

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