math/R slave ports and shared library

Fernando Herrero Carrón elferdo at
Tue Oct 4 06:38:01 UTC 2016

2016-10-04 4:59 GMT+02:00 Joseph Mingrone <jrm at>:

> After some surgery, math/R is in more manageable shape.  But, the surgery
> broke two slave ports, math/libR and math/libRmath.  They have each been
> marked broken since June or July and I posted to ports@ about deleting
> them, but didn't get a response.
This is great work indeed. The huge Makefile was a pain to work with,
mainly because of the slave ports, so this is greatly appreciated.

> math/libRmath
> I'm not sure how widely used math/libRmath is today, but it's still
> described in R's main installation document (
> doc/manuals/r-release/R-admin.html#The-standalone-Rmath-library).  It
> *should* be straightforward to just incorporate math/libRmath's four files
> into math/R and then delete math/libRmath.  The directory for libRmath is
> under WRKSRC, but it's not included in the main Makefile, so I'd have to
> either patch the main Makefile or do something with post-build and
> post-install.  Is this palatable?
> ---
> post-build:
>         ${SETENV} ${MAKE_ENV} ${MAKE_CMD} -C ${WRKSRC}/src/nmath/standalone
> post-install
> .for f in libRmath.a${RMATH_SOVERSION}
>         ${INSTALL_DATA} ${WRKSRC}/src/nmath/standalone/${f}
> ${STAGEDIR}/lib/
> .endfor
>         ${INSTALL_DATA} ${WRKSRC}/src/nmath/standalone/Rmath.h
> ${STAGEDIR}/include/
> ---
I would be very surprised (though it cannot be excluded) to see C programs
using libRmath. There are some questions on StackOverflow about developing
and distributing libRmath, so this cannot be 100% excluded [2]. The de
facto standard for R/C++ interoperability is Rcpp [1]. I am not sure
whether Rcpp can be built standalone, but it being an R package, I suspect
it needs a full R installation. Its main use is for R to include C++ code,
no the other way around.

All in all, I don't see much use for a standalone libRmath, but it cannot
be excluded. The truth being told, I would expect newer scientific software
coming from python+scipy+numpy rather than from R embedded in C/C++.

> Right now, unlike upstream, math/R's shared library option is turned on by
> default.  This was done only in late June because a dependency,
> math/rkward-kde4, required it.  Upstream turns it off, for the reasons
> described in [1].  I'm inclined to remove the libR option from math/R's
> OPTIONS_DEFAULT and resurrect math/libR (or maybe math/R-libR by using
> PKGNAMESUFFIX) as a very simple slave port that just installs math/R with
> that option on.  math/rkward-kde4 could then depend on math/libR.  One
> issue is that, I believe, R's installed packages (packages installed from
> within R) and many of R's dependencies would have to be rebuilt after
> turning off the libR option.
I have done some little benchmarking myself with and without dynamic libR
and have not seen any noticeable differences in performance (though I have
left it off to be safe), but don't take this as conclusive, more testing
should be done. Packages certainly do need to be rebuilt after switching
from dynamic libR to static. I can't tell what happens the other way
around. Ports-installed packages could be automatically recompiled, but
recompiling user-installed packages is a different story.

I think having two separate installations, whose packages would be mutually
exclusive is too dangerous and too easy for the user to mess up. I can
perform some more extensive benchmarks and see if having it enabled by
default really hurts.

In my opinion, performancewise I would only leave LTO and OPENMP as default
options. Even long double is not guaranteed to provide better precision
than double and it is very possible (per theory and per experience) that it
hinders performance [3].

Kind regards,


More information about the freebsd-ports mailing list