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

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.