Bug 199124

Summary: math/openblas: [PATCH] update to 0.2.14
Product: Ports & Packages Reporter: Johannes M Dieterich <jmd>
Component: Individual Port(s)Assignee: Bartek Rutkowski <robak>
Status: Closed FIXED    
Severity: Affects Only Me CC: demon, phd_kimberlite, robak
Priority: --- Keywords: patch
Version: LatestFlags: phd_kimberlite: maintainer-feedback+
Hardware: Any   
OS: Any   
Description Flags
svn diff of math/openblas v0.2.14
svn diff against r383155
patch to R383534 phd_kimberlite: maintainer-approval+

Description Johannes M Dieterich freebsd_committer 2015-04-02 21:00:39 UTC
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 :

	* 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

	* Support AMD Streamroller.

	* 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.

Comment 1 commit-hook freebsd_committer 2015-04-03 17:25:28 UTC
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

  math/openblas: update 0.2.13 -> 0.2.14

  PR:		199124
  Submitted by:	Johannes Dieterich <dieterich.joh@gmail.com>

Comment 2 Bartek Rutkowski freebsd_committer 2015-04-03 17:26:59 UTC
Committed, thanks for your work!
Comment 3 Dmitry Sivachenko freebsd_committer 2015-04-07 19:12:27 UTC
Re-open: I reverted this change because it fails to build with option OPENMP.
Maintainer review is also required.
Comment 4 Johannes M Dieterich freebsd_committer 2015-04-07 23:18:10 UTC
Created attachment 155321 [details]
svn diff against r383155
Comment 5 Johannes M Dieterich freebsd_committer 2015-04-07 23:22:41 UTC
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.
Comment 6 Eijiro Shibusawa 2015-04-11 23:47:15 UTC
Created attachment 155487 [details]
patch to R383534


I think libopenblasp is still needed because other port has dependency to it (see blaslapack.mk).
The attached is passed poudriere test.

Best regards,
Comment 7 Johannes M Dieterich freebsd_committer 2015-04-12 23:01:12 UTC
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)?
Comment 8 commit-hook freebsd_committer 2015-04-26 09:41:51 UTC
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

  Update to version 0.2.14

  PR:		199124
  Submitted by:	dieterich.joh@gmail.com
  Reviewed by:	maintainer

  Also remove deprecated GH_COMMIT.

Comment 9 Dmitry Sivachenko freebsd_committer 2015-04-26 09:43:12 UTC
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.