Provide both shlib and standard versions of R?

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 at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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