Skip to content

Provide both shlib and standard versions of R?

8 messages · Simon Urbanek, Bo Peng, elijah wright +2 more

Original
Bo Peng
# 
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
Simon Urbanek
#
On Jan 15, 2006, at 11:21 PM, Bo Peng wrote:

            

      
      
      
    

        
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.

            

      
      
      
    

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

Simon

  
  


  


      

    

    

      
      

        


  

        

      Bo Peng
    

    

      
      #
    

  


  

          

      
      
      
    

        
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

  
  


  


      

    

    

      
      

        


  

        

      Bo Peng
    

    

      
      #
    

  


  

          

      
      
      
    

        
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

  
  


  


      

    

    

      
      

        


  

        

      elijah wright
    

    

      
      #
    

  


  

          

      
      
      
    

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

on debian:

elw at 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

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Mon, 16 Jan 2006, Bo Peng wrote:

        

            

      
      
      
    

        
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

            

      
      
      
    

        
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.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Bo Peng
    

    

      
      #
    

  


  

          

      
      
      
    

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

            

      
      
      
    

        
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.

            

      
      
      
    

        
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

  
  


  


      

    

    

      
      

        


  

        

      Martyn Plummer
    

    

      
      #
    

  


  

      
On Mon, 2006-01-16 at 00:45 -0600, Bo Peng wrote:

            

      
      
      
    

        
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

            

      
      
      
    

        

      
      
    

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