math/R slave ports and shared library

Joseph Mingrone jrm at FreeBSD.org
Tue Oct 4 03:14:45 UTC 2016


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.

math/libRmath
I'm not sure how widely used math/libRmath is today, but it's still described in R's main installation document (https://cran.r-project.org/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 libRmath.so libRmath.so.${RMATH_SOVERSION}
	${INSTALL_DATA} ${WRKSRC}/src/nmath/standalone/${f} ${STAGEDIR}/lib/
.endfor	
	${INSTALL_DATA} ${WRKSRC}/src/nmath/standalone/Rmath.h ${STAGEDIR}/include/
---

math/libR
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.

Opinions?

Joseph

[1] "--enable-R-shlib causes the make process to build R as a dynamic (shared) library, typically called libR.so, and link the main R executable R.bin against that library. This can only be done if all the code (including system libraries) can be compiled into a dynamic library, and there may be a performance [47] penalty. So you probably only want this if you will be using an application which embeds R. Note that C code in packages installed on an R system linked with --enable-R-shlib is linked against the dynamic library and so such packages cannot be used from an R system built in the default way. Also, because packages are linked against R they are on some OSes also linked against the dynamic libraries R itself is linked against, and this can lead to symbol conflicts."

[47] We have measured 15-20% on i686 Linux and around 10% on x86_64 Linux.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20161003/a5b88d22/attachment-0001.sig>


More information about the freebsd-ports mailing list