Date: Tue, 26 Jul 2016 20:00:44 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 211393] math/R: update patches and options Message-ID: <bug-211393-13@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211393 Bug ID: 211393 Summary: math/R: update patches and options Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Keywords: patch Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: freebsd-ports-bugs@FreeBSD.org Reporter: jrm@ftfl.ca Attachment #173018 maintainer-approval+ Flags: Created attachment 173018 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D173018&action= =3Dedit svn diff to improve math/R Proposed changes: - Always build the shared library, libR. I can't think of a good reason no= t to always turn this on. Unless I'm missing a use-case, this eliminates the ne= ed from math/libR. - Memory profiling can cause problems with external BLAS, so only turn on memory profiling with R's internal BLAS. - Use R's internal BLAS by default. The authors recommend the internal BLAS for most use cases, because it is more widely tested. I've also encountered occasional segmentation faults with OpenBLAS. Any potential speed gains wi= th machine-customized OpenBLAS, if any at all, shouldn't trump stability. - Add ONLY_FOR_ARCHS=3Di386 amd64. Building on ARMv6 fails (even with the updated patches that were relevant for ARMv6) and, I'm told, there are other run-time problems related to calling fortran libraries from C on ARMv6. I don't have any powerpc hardware (yet) to test on. Anyone interested in tes= ting there? - Add a workaround for broken autoconf JPEG detection. - Don't force GCC as the C compiler. This has implications for dependent p= orts and wen@ should provide feedback before this is committed. [1] - Present the options organized by major dependencies. For example, group = LTO and OPENMP together because they, for now, both require GCC. Newer version= s of clang support both, so we can look into turning these options on by default soon. - LIBMISSING is no longer required because support for ARMv6 and powerpc ha= ve been removed. My guess is that it wouldn't be required (without LONGDOUBLE= ) in any case with the removed workarounds for quadmath. - Remove the THREADS options. The configure flags --enable-threads=3Dposix versus --disable-threads doesn't seem to have any effect on the build. - Remove patches that are no longer required, because they have been fixed upstream. The workaround in patch-src_extra_tre_tre-internal.h has been included upstream, but an #include <stdint.h> is missing. This is the only line in the updated patch. [1] I see cran.mk has .if ${cran_ARGS:Mcompiles} .include "${PORTSDIR}/math/R/compiler.mk" .endif A quick search shows ./R-cran-lme4 ./R-cran-memisc ./R-cran-MCMCpack ./R-cran-influenceR ./R-cran-mcmc ./R-cran-RcppArmadillo ./R-cran-Rcpp ./R-cran-tibble would be affected. Wen, can you suggest how you would like to handle this? It would be nice to not force GCC if it's a reasonable change for these dependent ports. portlint:=20 WARN: Makefile: unless this is a master port, PORTNAME has to be set by "= =3D", not by "?=3D". WARN: Makefile: do not call install-info directly. Use the INFO macro inst= ead. (spurious) testport: OK (poudriere: 9.3-RELEASE-p44, i386, default options) testport: OK (poudriere: 9.3-RELEASE-p44, amd64, default options) testport: OK (poudriere: 10.3-RELEASE-p5, i386, default options) testport: OK (poudriere: 10.3-RELEASE-p5, amd64, default options) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-211393-13>