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 > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ----------------------------------------------------------------------- This message and its attachments are strictly confidential. ...{{dropped}} ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel