math/R slave ports and shared library

Joseph Mingrone jrm at
Sun Oct 9 16:34:51 UTC 2016

Fernando Herrero Carrón <elferdo at> writes:
> 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++.

Given that 1) the port has been marked broken for so long and 2) only you responded to the last call for deletion back in July with a similar response, I'm feeling more comfortable about removing math/libRmath.

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

The same applies for math/libR.  For now, users who don't want the shared library can easily build their own port.

Thanks for your input Fernando,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: <>

More information about the freebsd-ports mailing list