Created attachment 155131 [details] svn diff of math/openblas v0.2.14 Find attached the trivial patch to update the port to upstream version 0.2.14. From http://www.openblas.net/Changelog.txt : common: * Improve OpenBLASConfig.cmake. * Improve ger and gemv for small matrices by stack allocation. e.g. make -DMAX_STACK_ALLOC=2048 * Introduce openblas_get_num_threads and openblas_get_num_procs. * Add ATLAS-style ?geadd function. * Fix c/zsyr bug with negative incx. * Fix race condition during shutdown causing a crash in gotoblas_set_affinity(). x86/x86-64: * Support AMD Streamroller. ARM: * Add Cortex-A9 and Cortex-A15 targets. Please note: MAX_STACK_ALLOC is not on by default (and this patch does not change this behavior). As this is a platform dependent size, I suspect it may be best to leave this off for the time being. Tested the new port version on amd64 11-CURRENT against a large Fortran code base without regressions. Thanks!
A commit references this bug: Author: robak Date: Fri Apr 3 17:25:06 UTC 2015 New revision: 383155 URL: https://svnweb.freebsd.org/changeset/ports/383155 Log: math/openblas: update 0.2.13 -> 0.2.14 PR: 199124 Submitted by: Johannes Dieterich <dieterich.joh@gmail.com> Changes: head/math/openblas/Makefile head/math/openblas/distinfo
Committed, thanks for your work!
Re-open: I reverted this change because it fails to build with option OPENMP. Maintainer review is also required.
Created attachment 155321 [details] svn diff against r383155
Indeed the OPENMP option seems to be broken. Thanks for noting! It seems the problem got introduced earlier, as the Makefile always defined USE_OPENMP=1 and USE_THREAD=0, which cannot be done. Just 0.2.14 explicitly checks this now. However, I propose the attached patch which also does disable compilation of the libopenblasp.so/.a if OPENMP is not enabled. I see little value in having a second library around without OpenMP support. Please note that the patch is against r383155, i.e., before the revert. This is patched to compile and install on amd64-CURRENT both w/ and w/o OPENMP enabled.
Created attachment 155487 [details] patch to R383534 Hi, I think libopenblasp is still needed because other port has dependency to it (see blaslapack.mk). The attached is passed poudriere test. Best regards,
If a parallel library is indeed wished for by some other ports, why would this port "really" only provide it after explicit configuration? Hence, should the OpenMP option not be implicit default, even though this means relying on lang/gcc (until llvm/clang has proper OpenMP support, i.e., 3.7/3.8-ish)?
A commit references this bug: Author: demon Date: Sun Apr 26 09:41:31 UTC 2015 New revision: 384769 URL: https://svnweb.freebsd.org/changeset/ports/384769 Log: Update to version 0.2.14 PR: 199124 Submitted by: dieterich.joh@gmail.com Reviewed by: maintainer Also remove deprecated GH_COMMIT. Changes: head/math/openblas/Makefile head/math/openblas/distinfo
I committed the proposed patch for update to new version (0.2.14). I propose to continue discussion about USE_OPENMP and libopenblas vs libopenblasp in new PR.