[Rd] Possible bug: How does libR.so find RHOME?

[Simon Anders]

Hi

While installing RPy2, I had curious problems which, if I traced them
back correctly, have their root in the way that libR.so find the R
installation directory. I wonder if this might be a subtle bug that only
causes problems when one has several versions of R on one system but
then can be very annoying and cause very strange behaviour.

It seems to me that libR.so asks the Unix shell to execute "R RHOME" or
something similar, and this causes problems, as detailed below.

We have several R installations on our server (a CentOS Linux, version
4.6, x86_64 machine), and in my shell environment, the symlink "R" that
is found in the system search path points to a static build of R-2.8.1,
while the symlink "R-2.9" points to today's R-2.9.beta, built with
'--enable-shlib'. (What follows is true, however, for R 2.8.1, built as
a library, as well.)

The setup.py script of RPy2 calls "R RHOME" to find R and then compiles
its C code to a shared object that is linked to libR.so. It uses the
'-R' linker option to store the full path to libR.so.

As "R RHOME" would have returned the path to my static R-2.8
installation, I specified the RHOME path to my R-2.9 library build
explicitly to RPy2's setup.py by means of an environment variable that
is checked by the script. This resulted in an RPy2 installation properly
linked to my R-2.9.

However, on starting RPy2 in Python, I got this strange error:

  >>> from rpy2 import robjects
  Error in grep("(_US|_CA)", lcpaper) :
    8 arguments passed to .Internal(grep) which requires 9
  [...]

RPy2 started up nevertheless, but failed to load the base packages, so
that all standard functions were missing.

Changing the "R" symlink in my search path to point to the R-2.9 version
against which RPy2 is linked solved the problem. It seems that, before,
the R-2.9 libR.so tried to load the base environment of R-2.8, because
R-2.8 was in the search path.

As a further check, I put an empty script called "R" that does nothing
into the search path. Then I get this:

   >>> from rpy2 import robjects
   cannot find system Renviron
   Fatal error: unable to open the base package

My guess is that it is libR.so (and not RPy2) that locates the R
executable in the path. If this is so, this seems to be a bug to me: An
application (let alone a shared library) should not rely on the names of
symlinks in the user's search path.

Best regards
  Simon


+---
| Dr. Simon Anders, Dipl. Phys.
| European Bioinformatics Institute, Hinxton, Cambridgeshire, UK
| office phone +44-1223-492680, mobile phone +44-7505-841692
| preferred (permanent) e-mail: sanders at fs.tum.de