[Rd] Re: [Omega-remote] Installing RSPython with R 1.3.0

Kurt Hornik Kurt.Hornik@ci.tuwien.ac.at
Sun, 29 Jul 2001 22:42:41 +0200

>>>>> Duncan Temple Lang writes:

> 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.

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

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 ...

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