Skip to content

Installing RSPython with R 1.3.0

5 messages · Gregory R. Warnes, Duncan Temple Lang, A.J. Rossini +1 more

Original
Gregory R. Warnes
# 
To get RSPython installed on my debian test box, I had to make a couple
of changes not listed in
ftp://www.omegahat.org/pub/Omega/RSPython/FAQ.html 

1) I had to change $R_HOME/src/modules/X11 :

$(R_X11_la): $(R_X11_la_OBJECTS) $(R_X11_la_DEPENDENCIES)
        $(SHLIB_LINK) -o $@ $(R_X11_la_LDFLAGS) $(R_X11_la_OBJECTS)
$(R_X11_la_LIBADD) $(LIBS) 

to

$(R_X11_la): $(R_X11_la_OBJECTS) $(R_X11_la_DEPENDENCIES)
        $(SHLIB_LINK) -o $@ $(R_X11_la_LDFLAGS) $(R_X11_la_OBJECTS)
$(R_X11_la_LIBADD) $(LIBS) -L$(R_HOME)/bin -lR

2) I had the same link problem with ctest, so I changed

PKG_LIBS =  -lg2c -lm -L/usr/lib/gcc-lib/i386-linux/2.95.4 -lm

to

PKG_LIBS =  -lg2c -lm -L/usr/lib/gcc-lib/i386-linux/2.95.4 -lm
-L$(R_HOME)/bin -lR


3)  Will all libraries that get loaded into R inside of python require
this?


If I try to load other 'recommended' packages that include C code I get
dyn.load erros, EG:
Error in dyn.load(x, as.logical(local), as.logical(now)) :
        unable to load shared library
"/usr/local/lib/R/library/splines/libs/splines.so":
  /usr/local/lib/R/library/splines/libs/splines.so: undefined symbol:
R_NaN
Error in function (package, help, lib.loc = .lib.loc, character.only =
FALSE,  :
        .First.lib failed
In the local error handler
In the local error handler
Error in if (!is.numeric(name) || name != (pos <- as.integer(name))) { :
        missing value where logical needed
In the local error handler
In the local error handler
Error in pos.to.env(pos) : invalid argument
In the local error handler
In the local error handler
Error in objects(lib.pos) : invalid envir= argument
In the local error handler
['RSPython', 'ctest', 'base']

-Greg
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
A.J. Rossini
# 
I'm not seeing this:

121$ python
Python 1.5.2 (#0, Apr 10 2001, 10:03:44)  [GCC 2.95.3 20010219
(prerelease)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Initialized R-Python interface package.
['splines', 'RSPython', 'ctest', 'base']
for example.  

I made a slightly different set of changes (I didn't make the ones you
suggested, Greg).

I'd be happy to email a copy of the new version
(RSPython_0.3-1ajr.tar.gz, use as RSPython_0.3-1.tar.gz) which has
configure patched to find the Debian default locations of things; it
would be interesting to see if it works for you (it did for me on 2
Sid/unstable boxes).

best,
-tony
GRW> To get RSPython installed on my debian test box, I had to
    GRW> make a couple of changes not listed in
    GRW> ftp://www.omegahat.org/pub/Omega/RSPython/FAQ.html

    GRW> 1) I had to change $R_HOME/src/modules/X11 :

    GRW> $(R_X11_la): $(R_X11_la_OBJECTS) $(R_X11_la_DEPENDENCIES)
    GRW> $(SHLIB_LINK) -o $@ $(R_X11_la_LDFLAGS) $(R_X11_la_OBJECTS)
    GRW> $(R_X11_la_LIBADD) $(LIBS)

    GRW> to

    GRW> $(R_X11_la): $(R_X11_la_OBJECTS) $(R_X11_la_DEPENDENCIES)
    GRW> $(SHLIB_LINK) -o $@ $(R_X11_la_LDFLAGS) $(R_X11_la_OBJECTS)
    GRW> $(R_X11_la_LIBADD) $(LIBS) -L$(R_HOME)/bin -lR

    GRW> 2) I had the same link problem with ctest, so I changed

    GRW> PKG_LIBS = -lg2c -lm -L/usr/lib/gcc-lib/i386-linux/2.95.4 -lm

    GRW> to

    GRW> PKG_LIBS = -lg2c -lm -L/usr/lib/gcc-lib/i386-linux/2.95.4 -lm
    GRW> -L$(R_HOME)/bin -lR


    GRW> 3) Will all libraries that get loaded into R inside of python
    GRW> require this?


    GRW> If I try to load other 'recommended' packages that include C
    GRW> code I get dyn.load erros, EG:

    >>>> RS.call("library","splines")
    GRW> Error in dyn.load(x, as.logical(local), as.logical(now)) :
    GRW> unable to load shared library
    GRW> "/usr/local/lib/R/library/splines/libs/splines.so":
    GRW> /usr/local/lib/R/library/splines/libs/splines.so: undefined
    GRW> symbol: R_NaN Error in function (package, help, lib.loc =
    GRW> .lib.loc, character.only = FALSE, : .First.lib failed In the
    GRW> local error handler In the local error handler Error in if
    GRW> (!is.numeric(name) || name != (pos <- as.integer(name))) { :
    GRW> missing value where logical needed In the local error handler
    GRW> In the local error handler Error in pos.to.env(pos) : invalid
    GRW> argument In the local error handler In the local error
    GRW> handler Error in objects(lib.pos) : invalid envir= argument
    GRW> In the local error handler ['RSPython', 'ctest', 'base']

    GRW> -Greg _______________________________________________
    GRW> Omega-remote mailing list - Omega-remote@www.omegahat.org
    GRW> http://www.omegahat.org/mailman/listinfo/omega-remote
Duncan Temple Lang
# 
Hi Greg.

  What you are seeing is probably a result of using R embedded within another
application/system (Python in this case) but having R originally compiled
without support for R as a shared library. If you were to build R in the default
manner, i.e.
    configure
    make
and then re-configure to build as a shared library
    configure --enable-R-shlib
    make
the shared objects that make up the modules and package libraries
will not be rebuilt. Perhaps they should, but that is not currently
what happens.

 If you were to start afresh (e.g. make distclean) 
and then configure with shared library support
(
    configure --enable-R-shlib
    make
)
all should be well and all the .so's that R attempts to load will
also be linked against libR.so and so the symbols within R on which
they depend will be located.

  Hope this is the correct diagnosis of the problem.

     D.
Gregory R. Warnes wrote:
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
A.J. Rossini
# 
DTL>  If you were to start afresh (e.g. make distclean) and then
    DTL> configure with shared library support ( configure
    DTL> --enable-R-shlib make ) all should be well and all the .so's
    DTL> that R attempts to load will also be linked against libR.so
    DTL> and so the symbols within R on which they depend will be
    DTL> located.

And just to comment, with respect to Debian, this appears to have been
done by Doug.
5 days later
Kurt Hornik
# 
Corrent.  However, according to my understanding, re-configuring with a
different set of arguments is not guaranteed to work unless preceded by
make distclean ...

[Argh.  In any case, this means that when checking for the existence of
-lR at package configure time we cannot safely assume that the standard
modules were linked against -lR ... terrible.]

Btw, looking at RSPython's configure.in,

	if test -f "${R_HOME}/bin/libR.so" ; then
	  R_SHARED_LIBRARY="-lR"
	fi

has the `.so' hard-wired which it should not.  The quick solution would
be something like getting the value of LIBR from R_HOME/etc/Makeconf.
Longer term, ideally we should get this info via something like R CMD
config --libs ...

-k
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._