[Phylobase-devl] Rcpp and OS X compiliation

[Mark Holder]

Hi folks,
	Dirk, Romain Francois, Simon Urbanek, and I have had some more off- 
thread email exchanges about this issue.  I think that it is now  
resolved.


Speaking for the phylo-informatics community, I'd like to sincerely  
thank Dirk, Romain, and Simon for all of the help getting this sorted  
out.


The long term solution:
	Dirk and Romain are going to release Rcpp 0.7.3 soon. This version  
will cause phylobase to statically link to libRcpp. No changes to  
phylobase are required.


The short term solutions. Either:
	1. install Rcpp and phylobase from source, or
	2. augment your dynamic library loading path (for example add $HOME/ 
Library/R/2.10/library/Rcpp/lib/i386 to the list of directories in the  
DYLD_LIBRARY_PATH environmental variable on Mac).


Below I summarize the issues for those who are curious.



all the best,
Mark




The gory details (as I understand them):

1. shared (or "dynamic") libraries contain a path to their location.   
I think that this field can also be just the name, but by default it  
is the full path.  (On Mac, "otool -L libNAMEHERE.so"  lists this  
location. install_name_tool can be used to update this info).

2. executables or other libraries that link to a dylib store the path  
that the library lists for itself.  This info is used by the loader at  
runtime to find all of the object code that the calling code uses.

3. If the loader finds a library with the correct name in its search,  
then it will load the library (even if the calling library incorrectly  
lists its own location).  So the loading is robust to moving the  
library, if you move it to a directory that is on the search path (it  
still not a great idea to move your dynamic libraries after linking to  
them).

So, if phylobase was linked against libRcpp that was at /x/lib/ 
libRcpp.dylib (and libRcpp lists its own location as "/x/lib/ 
libRcpp.dylib") then when phylobase loads, it will be able to load the  
functions supplied by libRcpp:	
	- if libRcpp is still at /x/lib/libRcpp.dylib, OR
	- if there is a library called libRcpp.dylib in the directories that  
are always searched (eg. those libraries listed in DYLD_LIBRARY_PATH,  
or those directories that R specifies to the loader).

4. There is no binary package installation hook that would allow a  
dynamic library to be modified when it is installed via the  
install.packages mechanism.   So calling something like  
install_name_tool as part of package installation so that each library  
lists the correct (installed) location for itself is not an option.

Thus, when a binary form of phylobase was installed, it would refer to  
a path to libRcpp.dylib that does not exist on the user's machine (it  
will be a  a path on the build machine's filesystem).  So binary  
installs of phylobase  were brittle.

Furthermore, if one uses install.packages to install Rcpp, then the  
library that you download will have the wrong path listed for its own  
location.  If you then build phylobase against this version of the  
library, the build and link will work but the loader will look in the  
wrong place for the library (and the library(phylobase) call will fail).


The most robust solution seems to be static linking of Rcpp into  
phylobase.  After a statically-linked version of pyhlobase.so is  
created, then phylobase will no longer need to find libRcpp.*



Building from source also works because then all of the libraries list  
their own locations correctly.










Mark Holder

mtholder at ku.edu
http://www.people.ku.edu/~mtholder/

==============================================
Department of Ecology and Evolutionary Biology
University of Kansas
6031 Haworth Hall
1200 Sunnyside Avenue
Lawrence, Kansas 66045

lab phone:  785.864.5789

fax (shared): 785.864.5860
==============================================







-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.r-forge.r-project.org/pipermail/phylobase-devl/attachments/20100119/e92c92cd/attachment.htm