Installing R package with undefined symbol

Question

I have installed R-3.0.1 with intel13 and am trying to install reshape2 version 1.2.2. I am installing it from source with R CMD INSTALL reshape2 but I get the following error:

Error in dyn.load(file, DLLpath = DLLpath, ...) : 
  unable to load shared object '/sonas/hpcf/apps/R/install/intel13/3.0.1/lib64/R/library/stringi/libs/stringi.so':
  /sonas/hpcf/apps/R/install/intel13/3.0.1/lib64/R/library/stringi/libs/stringi.so: undefined symbol: _intel_fast_memmove
ERROR: lazy loading failed for package ‘reshape2’

So I am thinking that stringi.so was compiled (correctly?) with the shared intel libraries, but maybe reshape2 is not able to see those libraries? How do I go about installing reshape2 with the shared libraries necessary for defining the symbol _intel_fast_memmove ?

FYI, I am installing on RHEL 6.4

Answer 1

This problems occurs frequently enough in dynamic loading environments (such as R and Python) when more than one version of the Intel compiler is present on the system and is used to compile different things.

If R itself has been compiled with gcc, one possibility for this problem to occur is that stringi.so has been compiled with (old) Intel compiler v12.1.5 and another library (loaded into R previously) is compiled with newer Intel compiler 14.0.2. What happen is that the first library brings in some of the dependencies of the second, and since the dependencies are shared for shared library, the older ones aren't loaded and there is some change in name for those symbols hence the error. This is exactly what happened to with with Python, numpy and pytables.

Now, if you are not loading any other library, it could be that R itself has been built with a different version of the Intel compiler, however that is harder for me to imagine, since I would have rather expected a compile-time issue with stringi.so (assuming that it needs to link against R itself too).

Bottom line, you need to make sure that all the libraries loaded at runtime are compiled with the same version of the compiler. Mixing gcc and Intel compiler is saver than mixing two different versions of Intel compiler itself, in my experience.