Provide both shlib and standard versions of R?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Provide both shlib and standard versions of R?

Bo Peng-2
Dear list,

To operate R from python via a Python package rpy, R has to be
compiled with --enable-R-shlib.  This is troublesome since none of the
binary distributions (except for windows?) is built with this option
so rpy users have to build R from source. This can be quite a
challenge, especially on platforms like macOSX.

Is it possible to provide both standard and shlib version of R by
default? This may not be too hard for R (link twice? I am not quite
sure.) but will benefit all applications that embed R.

Cheers,
Bo

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Provide both shlib and standard versions of R?

Simon Urbanek

On Jan 15, 2006, at 11:21 PM, Bo Peng wrote:

> To operate R from python via a Python package rpy, R has to be  
> compiled with --enable-R-shlib.  This is troublesome since none of  
> the binary distributions (except for windows?) is built with this  
> option


That is not true, almost all binaries come with R as shared library -  
it is in fact the default on Mac OS X and Windows. Most Linux  
distributions provide a shared library binary as well.

>  so rpy users have to build R from source. This can be quite a  
> challenge, especially on platforms like macOSX.
>

I guess you didn't even try it, because on OS X it *is* the default!

Simon

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Provide both shlib and standard versions of R?

Bo Peng-2
> That is not true, almost all binaries come with R as shared library -
> it is in fact the default on Mac OS X and Windows. Most Linux
> distributions provide a shared library binary as well.

This would be good news. But at least, under linux,

./configure --help
  --enable-R-shlib        build the shared/dynamic library 'libR' [no]

This option is not enabled by default.

Bo

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Provide both shlib and standard versions of R?

elijah wright

>> That is not true, almost all binaries come with R as shared library -
>> it is in fact the default on Mac OS X and Windows. Most Linux
>> distributions provide a shared library binary as well.
>
> This would be good news. But at least, under linux,
>
> ./configure --help
>  --enable-R-shlib        build the shared/dynamic library 'libR' [no]
>
> This option is not enabled by default.

then either build your own with correct options or talk to your
distribution's packaging team.

on debian:

elw@illuminati:/usr/lib/R/lib$ ls -al /usr/lib/R/lib
total 2900
drwxr-xr-x  2 root root    4096 Jan 10 20:54 .
drwxr-xr-x 11 root root    4096 Jan 10 20:54 ..
-rw-r--r--  1 root root 1810072 Jan  7 20:44 libR.so
-rw-r--r--  1 root root 1139796 Jan  7 20:44 libRlapack.so
lrwxrwxrwx  1 root root      27 Jun  8  2005 libggobi.so -> ../../ggobi/lib/libggobi.so
lrwxrwxrwx  1 root root      28 Jun  8  2005 libgtkext.so -> ../../ggobi/lib/libgtkext.so


as you can see - there's clearly a nice libR.so sitting here.

--elijah

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Provide both shlib and standard versions of R?

Bo Peng-2
> then either build your own with correct options or talk to your
> distribution's packaging team.

It seems that my knowledge about this option is outdated.  When I
first encountered this problem two years ago, the R/rpm distribution
came with no libR.so. I was told that --enable-R-shlib would lead to
10% - 20% performance loss, and I had to re-compile R if I need to
embed it.

So I guess performance is no longer an issue and shared libraries are
provided as default on all platforms now? I certainly welcome this
change and I apologize for my unfounded accusation to R.

BTW, shouldn't --enable-R-shlib be yes by default during ./configure?.

Cheers,
Bo

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Provide both shlib and standard versions of R?

Prof Brian Ripley
On Mon, 16 Jan 2006, Bo Peng wrote:

>> then either build your own with correct options or talk to your
>> distribution's packaging team.
>
> It seems that my knowledge about this option is outdated.  When I
> first encountered this problem two years ago, the R/rpm distribution
> came with no libR.so. I was told that --enable-R-shlib would lead to
> 10% - 20% performance loss, and I had to re-compile R if I need to
> embed it.
>
> So I guess performance is no longer an issue and shared libraries are
> provided as default on all platforms now? I certainly welcome this
> change and I apologize for my unfounded accusation to R.

Why guess?  There are accurate statements in the R-admin manual, and the
RH RPM change was discussed on this list in 2006:

https://stat.ethz.ch/pipermail/r-devel/2006-January/036118.html

> BTW, shouldn't --enable-R-shlib be yes by default during ./configure?.

No, for the reasons given in the R-admin manual.  They include that there
are platforms on which --enable-R-shlib cannot be used.

We have been working (in R-devel) on changes which are designed to reduce
the overhead of the shlib version of R: they do, but it is still over 10%
on the platforms checked.  (The figures given earlier are optimistic in
the sense that they include time spent in compiled code in packages such
as stats in a typical R session: worst-case scenarios have up to double
that.)

Please do think hard before you tell other people what they `should' do
for you.

--
Brian D. Ripley,                  [hidden email]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Provide both shlib and standard versions of R?

Bo Peng-2
> Why guess?  There are accurate statements in the R-admin manual,

I read the manual 2 years ago, and the info I got was still correct.

> and the RH RPM change was discussed on this list in 2006:
> https://stat.ethz.ch/pipermail/r-devel/2006-January/036118.html

I simply do not know RPMs have been built with this option on, and
there is no definite place/word I can be assured about this.

> No, for the reasons given in the R-admin manual.

Even the reason I gave in my first email was not up to date (most
binary distributions are compiled with this option), my suggest is
still valid: why not provide two binaries? Most users can use standard
R without sacrificing performance  and embedding applications use
libR.so and, if needed, a separate binary R_embed.

Cheers,
Bo

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Provide both shlib and standard versions of R?

Martyn Plummer-2
In reply to this post by Bo Peng-2
On Mon, 2006-01-16 at 00:45 -0600, Bo Peng wrote:

> > then either build your own with correct options or talk to your
> > distribution's packaging team.
>
> It seems that my knowledge about this option is outdated.  When I
> first encountered this problem two years ago, the R/rpm distribution
> came with no libR.so. I was told that --enable-R-shlib would lead to
> 10% - 20% performance loss, and I had to re-compile R if I need to
> embed it.
>
> So I guess performance is no longer an issue and shared libraries are
> provided as default on all platforms now? I certainly welcome this
> change and I apologize for my unfounded accusation to R.

What changed was that a sufficient number of people asked me to create
an RPM with the shared library and I changed my mind.  The aim of the
precompiled binaries is to satisfy most of the people most of the time,
and when I get repeated requests for the same feature, I have to bear
that in mind. People who require optimal performance can still compile
their own.

As for the idea of compiling two distinct binaries packages for R, I am
not especially keen, and not just out of laziness. The problem is that R
packages depend on libR.so, when it exists, so if you uninstall R with a
shared library and then install R without the shared library you get a
broken system.

You can look at the CAPABILITIES file in the same directory as the RPM
to see how it was compiled.

Martyn

> BTW, shouldn't --enable-R-shlib be yes by default during ./configure?.
>
> Cheers,
> Bo
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-----------------------------------------------------------------------
This message and its attachments are strictly confidential. ...{{dropped}}

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel