Created attachment 244205 [details] patch The attached patch updates the port to 0.3.23. NOTE: - This port was tested with portlint 2.20.0 and poudriere 3.3.7 (13.2-p2 amd64). + with / without USE_GCC=12 knob - The patch to f_check handles the following problem + https://github.com/xianyi/OpenBLAS/issues/3015
Hi, Is this something we need to take into consideration? https://archlinux.org/news/openblas-0323-2-update-requires-manual-intervention/ Can we use upstream's release archive instead of the GitHub generated one? https://github.com/xianyi/OpenBLAS/releases/tag/v0.3.23 Can we drop the AVX/AVX2 options in favour of CPUTYPE? https://cgit.freebsd.org/src/tree/share/examples/etc/make.conf#n25 Gentoo seems to carry a few patches that might be beneficial for us too https://gitweb.gentoo.org/repo/gentoo.git/tree/sci-libs/openblas Thanks for working on this! Best regards, Daniel
(In reply to Daniel Engberg from comment #1) Hello Mr. Engberg, Thank you for replying to me. Could you please make a patch for the port? It’s been long time since I've raised a PR, so I don't have the enough understanding to discuss base system or other distribution. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262855 Because the port is required from many other ports, I would appreciate it if you would consider not to change it too much. Thanks in advance!
^Triage: Open since a committer already passed by here.
Created attachment 244787 [details] update to 0.3.24 (In reply to Daniel Engberg from comment #1) Hi, I' ve created a patch for latest 0.3.24. > Is this something we need to take into consideration? > https://archlinux.org/news/openblas-0323-2-update-requires-manual-intervention/ This issue is not related to the update created this time. The port contains optimized LAPACK routine and CBLAS/LAPACKE like previous version. I did not understand that why do you try to talk about issue on other linux distribution? > Can we use upstream's release archive instead of the GitHub generated one? > https://github.com/xianyi/OpenBLAS/releases/tag/v0.3.23 portlint does not report fatal error, so I think it is fine to leave it as is. > Can we drop the AVX/AVX2 options in favour of CPUTYPE? > https://cgit.freebsd.org/src/tree/share/examples/etc/make.conf#n25 NO, I think that it is the user's choice whether to enable or disable SIMD instructions. > Gentoo seems to carry a few patches that might be beneficial for us too > https://gitweb.gentoo.org/repo/gentoo.git/tree/sci-libs/openblas Again, I did not understand that why do you try to talk about issue on other linux distribution? Do you mean it is better to separate optimized LAPACK routine and CBLAS/LAPACKE from the port? So could you clarify your intentions or create a patch please? Thanks in advance!
They're packaging related, nothing specific to Linux. Portlint won't complain about existing upstream release archives because it has never been able to so. Porters Handbook recommends usage of release archives to avoid breakage and as of GitHub's service policy changes please switch as it will avoid breakage. See https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-master_sites-github for more information. Both AVX and AVX2 are SMID instructions? Port (OpenBLAS) also appears to violate C(XX)FLAGS policy. https://docs.freebsd.org/en/books/porters-handbook/book/#dads-cflags Looking at my local box, "cc -DCBLAS -c -O2 -pipe -march=tigerlake -fstack-protector-strong -fno-strict-aliasing -O2 -DSMALL_MATRIX_OPT -DMAX_STACK_ALLOC=2048 -DEXPRECISION -fopenmp -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DSMP_SERVER -DUSE_OPENMP -DNO_WARMUP -DMAX_CPU_NUMBER=64 -DMAX_PARALLEL_NUMBER=1 -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.20\" -msse3 -mssse3 -msse4.1 -mavx -mavx2 -march=skylake-avx512 -mavx2 -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -DASMNAME= -DASMFNAME=_ -DNAME=_ -DCNAME= -DCHAR_NAME=\"_\" -DCHAR_CNAME=\"\" -DNO_AFFINITY -I. -O2 -DSMALL_MATRIX_OPT -DMAX_STACK_ALLOC=2048 -DEXPRECISION -fopenmp -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DSMP_SERVER -DUSE_OPENMP -DNO_WARMUP -DMAX_CPU_NUMBER=64 -DMAX_PARALLEL_NUMBER=1 -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.20\" -msse3 -mssse3 -msse4.1 -mavx -mavx2 -march=skylake-avx512 -mavx2 -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -DASMNAME=cblas_strmv -DASMFNAME=cblas_strmv_ -DNAME=cblas_strmv_ -DCNAME=cblas_strmv -DCHAR_NAME=\"cblas_strmv_\" -DCHAR_CNAME=\"cblas_strmv\" -DNO_AFFINITY -I.. -I. -UDOUBLE -UCOMPLEX trmv.c -o cblas_strmv.o" Ideally we should rely on CPUTYPE for any type of CPU specific optimization in the tree whenever possible. Shared library support has always been prefered, https://docs.freebsd.org/en/books/porters-handbook/book/#bundled-libs-practices but I dont think you need a separate package for it unless it clashes with other ones in tree. Best regards, Daniel
(In reply to Daniel Engberg from comment #5) I think OpenBLAS does dynamic runtime dispatch for SIMD kernels. So the code is compiled multiple times for varying levels of instruction set dependencies and the correct variant then picked at runtime. So -mavx2 and friends should only be passed for some files, with others being compiled without such flags.
(In reply to Daniel Engberg from comment #5) Hi, I understood a packing problem, at least, partially. I'll fix distfile issue when I have a time, because I'll be busy for a while. However I am really disappointed in you because you don't provide any solution for that you pointed. You should understand the background of openblas software and also consider it's usability. I think that the most part of users are not interested in developer's issue but use of fast BLAS. > https://gitweb.gentoo.org/repo/gentoo.git/tree/sci-libs/openblas With one glance, I did not find the patch that contributs to abstraction of CPU optimization. Could please you specify the patch that may contribute the solution, otherwise that issue is also not related the problem that you pointed. > Both AVX and AVX2 are SMID instructions? YES, Both are SIMD instructions. I think your provided log may be the result of respecting your CFLAGS. The following is corresponding part of poudriere log of my freebsd box. === cc -DCBLAS -c -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -O2 -DSMALL_MATRIX_OPT -DMAX_STACK_ALLOC=2048 -DEXPRECISION -fopenmp -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DDYNAMIC_ARCH -DDYNAMIC_OLDER -DSMP_SERVER -DUSE_OPENMP -DNO_WARMUP -DMAX_CPU_NUMBER=64 -DMAX_PARALLEL_NUMBER=1 -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.20\" -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -DASMNAME= -DASMFNAME=_ -DNAME=_ -DCNAME= -DCHAR_NAME=\"_\" -DCHAR_CNAME=\"\" -DNO_AFFINITY -I. -O2 -DSMALL_MATRIX_OPT -DMAX_STACK_ALLOC=2048 -DEXPRECISION -fopenmp -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DDYNAMIC_ARCH -DDYNAMIC_OLDER -DSMP_SERVER -DUSE_OPENMP -DNO_WARMUP -DMAX_CPU_NUMBER=64 -DMAX_PARALLEL_NUMBER=1 -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.20\" -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -DASMNAME=cblas_strmv -DASMFNAME=cblas_strmv_ -DNAME=cblas_strmv_ -DCNAME=cblas_strmv -DCHAR_NAME=\"cblas_strmv_\" -DCHAR_CNAME=\"cblas_strmv\" -DNO_AFFINITY -I.. -I. -UDOUBLE -UCOMPLEX trmv.c -o cblas_strmv.o === I didn't understand why -march=tigerlake is generated, the port may generate -march=skylake-avx512 however tigerlake is not. There is no doubt that somewhat strange things occurred. The module cblas_* is only I/F and not the optimized kernel function, so it is hard to think that they contain SIMD instructions. The openblas is highly HW dependent so the discussion should be based on the poudriere log with default settings. Even if the default settings some of issue may not be reproduced.
(In reply to Robert Clausecker from comment #6) Yeah, that's probably the cause. It's a bit hard to make with all the Makefiles upstream uses for build. (In reply to Eijiro Shibusawa from comment #7) CPUTYPE is a feature we utilize in the ports tree, this should preferably be honored which it currently isn't. This may not however be feasonable in all causes, since I don't have in depth knowledge of (Open)BLAS and consumers of it I asked if it was something that could be improved. Robert mentioned a possible reason why it passes flags as it does during build so we can probably ignore this issue. Regarding the patches I was mainly curious about https://gitweb.gentoo.org/repo/gentoo.git/tree/sci-libs/openblas/files/openblas-0.3.23-shared-blas-lapack.patch if it made sense to package and possibly https://gitweb.gentoo.org/repo/gentoo.git/tree/sci-libs/openblas/files/openblas-0.3.23-parallel-make.patch .
Dear sirs, Could you commit the update and close this issue (if required), please? This update is important to reduce CPU detection related problem in the future. I would like to fix distfile issue, however, as a mentioned above I'll be busy for a while. (In reply to Daniel Engberg from comment #8) I knew you have no in-depth knowledge in BLAS software, so I didn't reply to you in the first time. I hope you become a great commiter like who contributed improving the usability of this port.
Thank you for the update. As diizzy has not come forward, I will process it now. Please note that OpenMP is not supported on arm, so your patch may cause the port to fail to build there. Will proceed with a build test shortly. You'll have to make the -lomp link conditional on architecture, or best, detect the availability of OpenMP and only put it in if supported.
Also, would you like this patch to be merged into the newly branched 2023Q4 quarterly branch? If so, please set the "merge-quarterly" flag to "?".
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=c45681ef5049357ef58d738865b821186b02578f commit c45681ef5049357ef58d738865b821186b02578f Author: Eijiro Shibusawa <phd_kimberlite@yahoo.co.jp> AuthorDate: 2023-10-02 22:58:15 +0000 Commit: Robert Clausecker <fuz@FreeBSD.org> CommitDate: 2023-10-04 19:59:58 +0000 math/openblas: update to 0.3.24 Changelog: https://github.com/OpenMathLib/OpenBLAS/releases/tag/v0.3.24 PR: 273219 math/openblas/Makefile | 3 +- math/openblas/distinfo | 6 ++-- math/openblas/files/patch-c_check (gone) | 11 -------- math/openblas/files/patch-common__arm.h | 4 +-- math/openblas/files/patch-exports_Makefile | 4 +-- math/openblas/files/patch-f_check | 45 ++++++++++++------------------ 6 files changed, 26 insertions(+), 47 deletions(-)
(In reply to Robert Clausecker from comment #10) 1. GCC supports OpenMP on armv7 just fine. 2. Clang also supports OpenMP on armv7, just not on FreeBSD. It's possible it's just a matter of enabling it, at worst it needs to be ported. But it shouldn't be too hard, it already works on Linux.
(In reply to Piotr Kubaj from comment #13) I did a build test and the port built fine on armv7. I believe my suspicions of there being a problem were unfounded. I primarily mentioned this because there had been such issues in the past and OpenMP is still not supported on armv7 by the base clang we ship.
(In reply to Robert Clausecker from comment #11) Thank you for handling this and testing port on armv7 platform! I have set "merge-quarterly" flag to "?".
(In reply to Eijiro Shibusawa from comment #15) Sorry, I forgot. Will do that with my next batch.
There is a problem with the new version bug #274284.
A commit in branch 2023Q4 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ae3a092647271843da6d1fb9a38fe7331185c088 commit ae3a092647271843da6d1fb9a38fe7331185c088 Author: Eijiro Shibusawa <phd_kimberlite@yahoo.co.jp> AuthorDate: 2023-10-02 22:58:15 +0000 Commit: Robert Clausecker <fuz@FreeBSD.org> CommitDate: 2023-10-09 07:42:23 +0000 math/openblas: update to 0.3.24 Changelog: https://github.com/OpenMathLib/OpenBLAS/releases/tag/v0.3.24 PR: 273219 (cherry picked from commit c45681ef5049357ef58d738865b821186b02578f) math/openblas/Makefile | 3 +- math/openblas/distinfo | 6 ++-- math/openblas/files/patch-c_check (gone) | 11 -------- math/openblas/files/patch-common__arm.h | 4 +-- math/openblas/files/patch-exports_Makefile | 4 +-- math/openblas/files/patch-f_check | 45 ++++++++++++------------------ 6 files changed, 26 insertions(+), 47 deletions(-)
There, all MFH'ed.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=2c83bd52e56ebe097db15d592401cab28f9f126a commit 2c83bd52e56ebe097db15d592401cab28f9f126a Author: Robert Clausecker <fuz@FreeBSD.org> AuthorDate: 2023-10-10 17:08:35 +0000 Commit: Robert Clausecker <fuz@FreeBSD.org> CommitDate: 2023-10-10 17:18:06 +0000 math/openblas: Revert "update to 0.3.24" On some amd64 CPUs, this change broke py-scipy during configure, and octave at runtime. In the end, octave kills the package builders. This reverts commit c45681ef5049357ef58d738865b821186b02578f. Approved by: portmgr (antoine) PR: 273219 MFH: 2023Q4 math/openblas/Makefile | 4 +-- math/openblas/distinfo | 6 ++-- math/openblas/files/patch-c_check (new) | 11 ++++++++ math/openblas/files/patch-common__arm.h | 4 +-- math/openblas/files/patch-exports_Makefile | 4 +-- math/openblas/files/patch-f_check | 45 ++++++++++++++++++------------ 6 files changed, 47 insertions(+), 27 deletions(-)
A commit in branch 2023Q4 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=3854b733b246f077a2a6efbb3c58cb8be7297615 commit 3854b733b246f077a2a6efbb3c58cb8be7297615 Author: Robert Clausecker <fuz@FreeBSD.org> AuthorDate: 2023-10-10 17:08:35 +0000 Commit: Robert Clausecker <fuz@FreeBSD.org> CommitDate: 2023-10-10 17:18:46 +0000 math/openblas: Revert "update to 0.3.24" On some amd64 CPUs, this change broke py-scipy during configure, and octave at runtime. In the end, octave kills the package builders. This reverts commit c45681ef5049357ef58d738865b821186b02578f. Approved by: portmgr (antoine) PR: 273219 MFH: 2023Q4 (cherry picked from commit 2c83bd52e56ebe097db15d592401cab28f9f126a) math/openblas/Makefile | 4 +-- math/openblas/distinfo | 6 ++-- math/openblas/files/patch-c_check (new) | 11 ++++++++ math/openblas/files/patch-common__arm.h | 4 +-- math/openblas/files/patch-exports_Makefile | 4 +-- math/openblas/files/patch-f_check | 45 ++++++++++++++++++------------ 6 files changed, 47 insertions(+), 27 deletions(-)
As requested by antoine (for portmgr), this update has been reverted as it broke py-scipy during configure and octave at runtime on some CPUs. Please check the issue and resubmit with corrections. We will then do an exp-run to ensure that the issue has indeed been resolved. Known bad CPU: CPU: Intel(R) Xeon(R) CPU E5-2690 v4 @ 2.60GHz (2600.15-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406f1 Family=0x6 Model=0x4f Stepping=1 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x7ffefbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM> AMD Features2=0x121<LAHF,ABM,Prefetch> Structured Extended Features=0x21cbfbb<FSGSBASE,TSCADJ,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,NFPUSG,PQE,RDSEED,ADX,SMAP,PROCTRACE> XSAVE Features=0x1<XSAVEOPT> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics Known good CPU: CPU: Intel(R) Xeon(R) Silver 4214 CPU @ 2.20GHz (2200.00-MHz K8-class CPU) Origin="GenuineIntel" Id=0x50657 Family=0x6 Model=0x55 Stepping=7 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x7ffefbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM> AMD Features2=0x121<LAHF,ABM,Prefetch> Structured Extended Features=0xd39ffffb<FSGSBASE,TSCADJ,BMI1,HLE,AVX2,FDPEXC,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,NFPUSG,MPX,PQE,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PROCTRACE,AVX512CD,AVX512BW,AVX512VL> Structured Extended Features2=0x818<PKU,OSPKE,AVX512VNNI> Structured Extended Features3=0xbc000400<MD_CLEAR,IBPB,STIBP,L1DFL,ARCH_CAP,SSBD> XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES> IA32_ARCH_CAPS=0x2b<RDCL_NO,IBRS_ALL,SKIP_L1DFL_VME,MDS_NO> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics Looks like the new openblas is either built with too many CPU features enabled or the dispatch logic (if there is any) doesn't work correctly.
(In reply to Robert Clausecker from comment #22) I’m sorry for the inconvenience to the users. Mr. Clausecker, thank you for handling revert request quickly. This problem seems difficult for me to provide some solution. So I will contact the upstream after some investigation. As you pointed the cause seems to be related to thread dispatching. Foe example, if I disabled OPENMP option the problem seems not to be reproduced.
(In reply to Eijiro Shibusawa from comment #23) With "dispatch logic" I was referring to the logic that decides which code to use based on the CPU features of the host. I am assuming that OpenBLAS has such logic, but I don't know for sure. Thank you for contacting upstream to get this working. Your effort is much appreciated.
The tag release/14.0.0 references this bug: URL: https://cgit.FreeBSD.org/ports/tag/?h=release/14.0.0 tag release/14.0.0 Tagger: Glen Barber <gjb@FreeBSD.org> TaggerDate: 2023-10-18 18:51:20 +0000 Tag release/14.0.0 for 14.0-RELEASE -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmUwKTsACgkQAxRYpUeP 4pNluw//bMV/OkfKmrgO9xC8lQdQpo5zWcpxi80U+21yRkyR7NSKypVOdGca39pi blDrOXl0EP9T2CuZs+ljhqKiRMn1z2FVS+71j6C6Tx8uX0gqf+8a1WZ0KAt09vgs JHa2oaM42vfdeoRSCb4WjK0RVnnyjXuZ8b7pOdWPjLqiddM5coITPbFHZ7yT93r1 svxOFDNGu5Aw+trLp3tpWu04cbZdquyeCHP1hwVN2md0urDevEQhZqJmtp1MvjIh FetBPlAI0IXxvBXTTJQSJzwfTC9h8SPFNpy0T8JCAvh52/bxkUYycG8a+k4TgYXC 7LNSdP4IsHGTwJhXkfR0fQJ9fwn/nwtZgkyQ7d+VsjcYN88B/nLA9VHdu1W0mrvX O9tCV+IYKm7WvAYHosS1ksCxHn0fawbyx1fjaTbHQGuE+L0rRwb8Qhp0WQqvaczD hHbNn+fTQCe1QspSez+B6XX0kVntoibGrNeEmHR92EVhxW7BWlmblQA87Iptprne yU7m6OWl/Bs7XUkwybctAmRFAD8BBRx0UBEe2g30UVkFK0Q4H0M+0ewwFc7ECDFp xU183XEiLDYm7LEL7dHfCm3S1brvjNT+9l2ItNEdGa2rzEypiIW6QE9O8jccJ+i5 agHAT99LFlaj8zTH3nR4u5dGd/4OU800Z6iQtOWCQz9DG4LZTf8= =xo31 -----END PGP SIGNATURE----- commit 3854b733b246f077a2a6efbb3c58cb8be7297615 Author: Robert Clausecker <fuz@FreeBSD.org> AuthorDate: 2023-10-10 17:08:35 +0000 Commit: Robert Clausecker <fuz@FreeBSD.org> CommitDate: 2023-10-10 17:18:46 +0000 math/openblas: Revert "update to 0.3.24" On some amd64 CPUs, this change broke py-scipy during configure, and octave at runtime. In the end, octave kills the package builders. This reverts commit c45681ef5049357ef58d738865b821186b02578f. Approved by: portmgr (antoine) PR: 273219 MFH: 2023Q4 (cherry picked from commit 2c83bd52e56ebe097db15d592401cab28f9f126a) math/openblas/Makefile | 4 +-- math/openblas/distinfo | 6 ++-- math/openblas/files/patch-c_check (new) | 11 ++++++++ math/openblas/files/patch-common__arm.h | 4 +-- math/openblas/files/patch-exports_Makefile | 4 +-- math/openblas/files/patch-f_check | 45 ++++++++++++++++++------------ 6 files changed, 47 insertions(+), 27 deletions(-)
No follow up within 14 days, return to pool. If you manage to get the update working correctly, please respond to this bug report with a new patch and we can continue with the process.
Comment on attachment 244787 [details] update to 0.3.24 This patch was backed out. Do not commit.
Hi, I carried out several investigation, so I'm interested in 1) reproduce method of octave issue (both CLANG and GCC build case); 2) check method of numerical correctness of scipy (built with GCC + OPENMP). Could someone let me know about the above, please? I think that the issue produces multiple problems i) build error; ii) (doubt of) numerical correctness issue. I tried investigations involve some different build conditions. [OpenBLAS 0.3.23 (CLANG + SET OPENMP)] * math/openblas -> OK (poudriere, their own regression test) * math/octave -> OK (poudriere) * science/py-scipy -> OK (poudriere) * lang/julia -> OK (poudriere) [OpenBLAS 0.3.24 (CLANG + SET OPENMP)] * math/openblas -> OK (poudriere, their own regression test) * math/octave -> OK (poudriere) <---- ??? * science/py-scipy -> NG (poudriere-runaway) * lang/julia -> NG (poudriere-runaway) [OpenBLAS 0.3.24 (GCC + SET OPENMP)] * math/openblas -> OK (poudriere, their own regression test) * math/octave -> OK (poudriere) * science/py-scipy -> OK (poudriere) * lang/julia -> OK (poudriere) [OpenBLAS 0.3.24 (CLANG + UNSET OPENMP)] * math/openblas -> OK (poudriere, their own regression test) * math/octave -> OK (poudriere) * science/py-scipy -> OK (poudriere) * lang/julia -> OK (poudriere) I think that a) it seems passed OpenBLAS's regression test in all case; b) it is strange that building octave always succeeds; c) building scipy and julia seems same build-runaway problem; d) the problem seems not reproduced under GCC + OpenMP or CLANG + UNSET OpenMP; e) the issue seems en-bug since v0.2.24. The CPU of my box is the following. === CPU: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz (2900.00-MHz K8-class CPU) Origin="GenuineIntel" Id=0xa0655 Family=0x6 Model=0xa5 Stepping=5 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x7ffafbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM> AMD Features2=0x121<LAHF,ABM,Prefetch> Structured Extended Features=0x29c67af<FSGSBASE,TSCADJ,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE> Structured Extended Features2=0x40000018<PKU,OSPKE,SGXLC> Structured Extended Features3=0xbc000400<MD_CLEAR,IBPB,STIBP,L1DFL,ARCH_CAP,SSBD> XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES> IA32_ARCH_CAPS=0x2b<RDCL_NO,IBRS_ALL,SKIP_L1DFL_VME,MDS_NO> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics === I'm sorry for delayed reply. If I obtain a solution to this problem I'll ask you an exp-run. Thanks in advance!
Hello, For octave, you can check if the following ports are hanging during run-depends phase: math/octave-forge-econometrics math/octave-forge-ncarray math/octave-forge-oct2mat math/octave-forge-tsa math/octave-forge-data-smoothing Also, the problem happened on our arm64 builder which has Ampere eMAG 8180 32-core cpu
(In reply to Antoine Brodin from comment #29) Thank you for your quick reply. octave-forge problems did not reproduce on my PC. So it is hard to say specific cause however v0.3.24 seems to contain multiple issues (OpenMP? and CPU feature? related).
Has this problem been reported upstream? I don't see it on <https://github.com/OpenMathLib/OpenBLAS/issues>: they might be helpful. E.g. such an error has been reported for MacPorts: <https://github.com/OpenMathLib/OpenBLAS/issues/4239>. This is not exactly the same one, but there are some common points. In their case it seems caused by a combination of some versions of clang × some version of the linker.
I have not reported this issue yet. Because I started working again yesterday and took some time to investigate reproducibility.
I have reported this problem to upstream. I welcome any additions or information to that issue. https://github.com/OpenMathLib/OpenBLAS/issues/4277
Hi, Could someone confirm the build failure port does not mix multiple OpenMP implementation please? The discussion in the upstream a comment ssays the following. > the small elephant in the room is that you are mixing GNU and LLVM compilers while using OpenMP, > which probably leads to linking against both libomp and libgomp in the same project > I suspect some of this multiple issue is not relevant to OpenBLAS. a) a comment says scipy build issue is solved to migrate meson-python build https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274284#c5 b) lang/julia has their own OpenMP and it is hard coded libgomp Thanks in advance!
(In reply to Eijiro Shibusawa from comment #34) Grepping julia’s build log shows the following: ln -sf /usr/local/lib/gcc12/libgomp.so.1 /wrkdirs/usr/ports/lang/julia/work/julia-1.9.3/usr/lib/julia/libgomp.so.1 and at the end this file is installed as $PREFIX/lib/julia/libgomp.so.1. This libgomp seems used to build .jl files, but the binaries installed by julia are not directly linked with it, nor with /usr/lib/libomp.so (it uses DL). Running julia under truss shows that it opens /usr/lib/libomp.so. I do not know julia, and I cannot say more, but if this is the cause of the problem it might be difficult to fix.
(In reply to Thierry Thomas from comment #35) Thank you! I confirmed the process which gets stuck is not mix conflicting OpenMP runtime. According to discussion in the upstream the "cause" of this issue is suspected to be OpenMP runtime related. I will continue investigation of this issue. The following is the process gets stuck: nobody 21250 100.0 0.9 442632 317184 1 RJ 19:55 6:02.15 /wrkdirs/usr/ports/lang/julia/work/julia-1.9.3/usr/bin/julia -Cgeneric -J/wrkdirs/usr/ports/lang/julia/work/julia-1.9.3/usr/lib/julia/sys.ji -O0 -g1 --startup-file=no -O0 --output-o /tmp/jl_K8F51k/compiled/v1.9/jl_XaSJdn --output-ji /tmp/jl_K8F51k/compiled/v1.9/jl_CT6DXq --output-incremental=yes --startup-file=no --history-file=no --warn-overwrite=yes --color=auto --trace-compile=/tmp/jl_K8F51k/jl_I9yfatyhCt - I did not found libgomp in the backtrace of that process: GNU gdb (GDB) 13.2 [GDB v13.2 for FreeBSD] Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd13.2". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) attach 21250 Attaching to process 21250 Reading symbols from /poudriere/data/.m/132amd64-local-workstation/01/wrkdirs/usr/ports/lang/julia/work/julia-1.9.3/usr/bin/julia... [New LWP 107526 of process 21250] warning: Could not load shared library symbols for 11 libraries, e.g. [vdso]. Use the "info sharedlibrary" command to see the complete listing. Do you need "set solib-search-path" or "set sysroot"? Reading symbols from /usr/lib/libdl.so.1... (No debugging symbols found in /usr/lib/libdl.so.1) Reading symbols from /lib/libthr.so.3... (No debugging symbols found in /lib/libthr.so.3) Reading symbols from /lib/libc.so.7... (No debugging symbols found in /lib/libc.so.7) Reading symbols from /usr/local/lib/libunwind.so.8... (No debugging symbols found in /usr/local/lib/libunwind.so.8) Reading symbols from /usr/lib/librt.so.1... (No debugging symbols found in /usr/lib/librt.so.1) Reading symbols from /usr/lib/libexecinfo.so.1... (No debugging symbols found in /usr/lib/libexecinfo.so.1) Reading symbols from /lib/libm.so.5... (No debugging symbols found in /lib/libm.so.5) Reading symbols from /lib/libelf.so.2... (No debugging symbols found in /lib/libelf.so.2) Reading symbols from /lib/libkvm.so.7... (No debugging symbols found in /lib/libkvm.so.7) Reading symbols from /usr/local/lib/gcc12/libatomic.so.1... (No debugging symbols found in /usr/local/lib/gcc12/libatomic.so.1) Reading symbols from /usr/lib/libc++.so.1... (No debugging symbols found in /usr/lib/libc++.so.1) Reading symbols from /lib/libcxxrt.so.1... (No debugging symbols found in /lib/libcxxrt.so.1) Reading symbols from /usr/lib/liblzma.so.5... (No debugging symbols found in /usr/lib/liblzma.so.5) Reading symbols from /lib/libz.so.6... (No debugging symbols found in /lib/libz.so.6) Reading symbols from /lib/libmd.so.6... (No debugging symbols found in /lib/libmd.so.6) Reading symbols from /usr/local/lib/libgmp.so.10... (No debugging symbols found in /usr/local/lib/libgmp.so.10) Reading symbols from /usr/local/lib/libmpfr.so.6... (No debugging symbols found in /usr/local/lib/libmpfr.so.6) Reading symbols from /usr/local/lib/gcc12/libquadmath.so.0... (No debugging symbols found in /usr/local/lib/gcc12/libquadmath.so.0) Reading symbols from /usr/lib/libomp.so... (No debugging symbols found in /usr/lib/libomp.so) Reading symbols from /libexec/ld-elf.so.1... (No debugging symbols found in /libexec/ld-elf.so.1) [Switching to LWP 100735 of process 21250] 0x000000085d00f452 in ?? () from /usr/lib/libomp.so (gdb) info threads Id Target Id Frame * 1 LWP 100735 of process 21250 0x000000085d00f452 in ?? () from /usr/lib/libomp.so 2 LWP 107526 of process 21250 0x00000008237cf15a in _sigwait () from /lib/libc.so.7 (gdb) t a a bt Thread 2 (LWP 107526 of process 21250): #0 0x00000008237cf15a in _sigwait () from /lib/libc.so.7 #1 0x000000082292395b in ?? () from /lib/libthr.so.3 #2 0x0000000828405dd2 in ?? () #3 0x0000000014004026 in ?? () #4 0x0000000000000000 in ?? () Thread 1 (LWP 100735 of process 21250): #0 0x000000085d00f452 in ?? () from /usr/lib/libomp.so #1 0x000000085d0287c8 in __kmp_acquire_ticket_lock () from /usr/lib/libomp.so #2 0x000000085d02e564 in ?? () from /usr/lib/libomp.so #3 0x000000085cfee91e in kmpc_malloc () from /usr/lib/libomp.so #4 0x000000085d0691b7 in ?? () from /usr/lib/libomp.so #5 0x000000085d038925 in ?? () from /usr/lib/libomp.so #6 0x000000085d02e5c4 in ?? () from /usr/lib/libomp.so #7 0x000000085d038ccc in ?? () from /usr/lib/libomp.so #8 0x000000085d038c94 in ?? () from /usr/lib/libomp.so #9 0x000000085d017d08 in omp_get_max_threads () from /usr/lib/libomp.so #10 0x00000008621774fb in ?? () #11 0x00000008638036f0 in ?? () #12 0x0000000000000010 in ?? () #13 0x000000086380097c in ?? () #14 0x0000000863800980 in ?? () #15 0x0000000820923c80 in ?? () #16 0x0000000862176ec7 in ?? () #17 0x0000000862176de0 in ?? () #18 0x0000000000000004 in ?? () #19 0x0000000300000006 in ?? () #20 0x5a23ef1d46289d3e in ?? () #21 0x00000008637de0d8 in ?? () #22 0x0000000831c7dc08 in ?? () #23 0x0000000831c7c588 in ?? () #24 0x0000000820924540 in ?? () #25 0x0000000820924100 in ?? () #26 0x00003399022fa0ad in ?? () from /libexec/ld-elf.so.1 #27 0x00000008211c8008 in ?? () #28 0x0000000000000000 in ?? () (gdb) detach Detaching from program: /poudriere/data/.m/132amd64-local-workstation/01/wrkdirs/usr/ports/lang/julia/work/julia-1.9.3/usr/bin/julia, process 21250 [Inferior 1 (process 21250) detached] (gdb) quit
Running `make test' with the current ports tree, i.e. with openblas-0.3.20,2, shows the hereunder failure: LinearAlgebra/structuredbroadcast (4) | started at 2023-11-12T22:22:21.327 From worker 7: Error: no BLAS/LAPACK library loaded! LinearAlgebra/symmetric (6) | 766.84 | 14.26 | 1.9 | 18986.41 | 1603.62 LinearAlgebra/blas (7) | failed at 2023-11-12T22:23:06.450 Test Failed at /usr/ports/lang/julia/work/julia-1.9.3/usr/share/julia/stdlib/v1.9/LinearAlgebra/test/blas.jl:680 Expression: BLAS.get_num_threads() === 1 Evaluated: 8 === 1 Test Failed at /usr/ports/lang/julia/work/julia-1.9.3/usr/share/julia/stdlib/v1.9/LinearAlgebra/test/blas.jl:699 Expression: BLAS.axpy!(α, a, copy(b)) ≈ α * a + b Evaluated: ComplexF64[1.9330187934128453 - 8.970730564994865im, -0.6963896877405945 + 0.8611170231579576im, -0.6963896877405945 + 0.8611170231579576im, -0.6963896877405945 + 0.8611170231579576im, -0.6963896877405945 + 0.8611170231579576im, -0.6963896877405945 + 0.8611170231579576im, -0.6963896877405945 + 0.8611170231579576im, -0.6963896877405945 + 0.8611170231579576im, -0.6963896877405945 + 0.8611170231579576im, -0.6963896877405945 + 0.8611170231579576im] ≈ ComplexF64[-0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im] Test Failed at /usr/ports/lang/julia/work/julia-1.9.3/usr/share/julia/stdlib/v1.9/LinearAlgebra/test/blas.jl:721 Expression: 23.0 === #= /usr/ports/lang/julia/work/julia-1.9.3/usr/share/julia/stdlib/v1.9/LinearAlgebra/test/blas.jl:721 =# @ccall(($dot_sym)(2::Int, [2.0, 3.0]::Ref{Cdouble}, 1::Int, [4.0, 5.0]::Ref{Cdouble}, 1::Int)::Cdouble) Evaluated: 23.0 === 5.0 That means that we already have a problem ATM with OpenBLAS and Julia. I have not [yet?] found the cause of this error, but the part "From worker 7" suggests something wrong with multi-threading…
Created attachment 246307 [details] update to 0.3.25 Hi, I have created the update to v0.3.25 including the workaround of OpenMP runtime related problem. I could not reproduce the octave-related and ARM architecture-related problem, so could you carefully do exp-run please? > That means that we already have a problem ATM with OpenBLAS and Julia. I have not [yet?] found the cause of this error, but the part "From worker 7" suggests something wrong with multi-threading… Thank you very much for investigating that problem. However I'm sorry, at least partially, I think it is not openblas problem but julia porting. This error should be fixed and... > From worker 7: Error: no BLAS/LAPACK library loaded! the following error disappears when I remove the ports patch files/patch-stdlib_LinearAlgebra_src_lbt.jl. > Expression: BLAS.get_num_threads() === 1 > Evaluated: 8 === 1 That patch seems to remove lbt_set_num_threads function call, so set / get number of threads unit test fail... Thanks in advance!
Hello portmgr, Could you please launch an exp-run with the upgrade to 0.3.25? (at least a partial one)
(In reply to Thierry Thomas from comment #35) I finally managed to remove the linkage on libgomp (and the other libraries which come with gfortran) in commit 47322ff8ea597f8c6bddcbb0bd33e9dcbc584492. This does not fix the problem reported at <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273219#c37>, but at least the port is clean about a possible conflict between libomp and libgomp.
Some new failure log: https://pkg-status.freebsd.org/package22/data/132amd64-default-foo/2023-11-18_08h04m12s/logs/errors/gcta-1.94.1.log
(In reply to Antoine Brodin from comment #41) Hi, I do not think that build error is OpenBLAS issue. It was caused a change introduced with LAPACK version 3.10. The LAPACK function call in GCTA may be updated in one of the following ways: https://github.com/OpenMathLib/OpenBLAS/issues/3877 > The correct way should be to add the "1" for the length of the single-character "U" argument at the end of your dpbtrf line, but as you wrote you could also comment the definition of LAPACK_FORTRAN_STRLEN_END to stay with the old behaviour (which has been implicated in a few otherwise unexplained problems as seen in the Reference-LAPACK issue ticket and others mentioned therein). The background is explained in that issue. https://github.com/OpenMathLib/OpenBLAS/issues/2154
Cc: Jason <jwb@FreeBSD.org> for information on this issue with GCTA.
Created attachment 246414 [details] experimental patch for biology/gcta Hi, I tried to the attached patch (for GCTA) and confirmed that math/openblas 0.3.25 and biology/gcta 1.94.1 pass poudriere test on 14.0R-amd64. However I think patching all LAPACK calls is NOT a good solution. By the way I also tested outdated OpenBLAS 0.3.24 port on the 14.0-RELEASE and could not reproduce py-scipy build error, so that problem is still possibly due to OpenMP runtime.
(In reply to Thierry Thomas from comment #43) Oddly, there's no sign of the pkg-fallout message in my mailboxes. But, gcta is building fine for me with current ports.
(In reply to Jason W. Bacon from comment #45) Indeed, this is an exp-run, and the failure occurs only when upgrading OpenBLAS to 0.3.25: see the patch attached in this PR.
(In reply to Thierry Thomas from comment #46) Oops, tired eyes. Thanks for the head-up.
Comment on attachment 246414 [details] experimental patch for biology/gcta Ask biology/gcta maintainer for approval of the experimental patch.
(In reply to Robert Clausecker from comment #48) Is there a reason the calls not updated under GCTA_CPU_x86, or is this just a minimal fix to resolve the errors on the tester's equipment?
(In reply to Jason W. Bacon from comment #49) I see what's going on now. The GCTA_CPU_x86 macro (mostly) enables MKL functions in place of OpenBLAS. Rather misleading name... Still, there are many calls to dgeqrf_(), etc. that are not altered by this patch. I'll have a closer look and get back to you ASAP.
(In reply to Jason W. Bacon from comment #50) Notified GCTA upstream: https://github.com/jianyangqt/gcta/issues/59 Updated port including documented versions of your suggested patches is here: https://github.com/outpaddling/freebsd-ports-wip/tree/master/gcta I'd be OK with committing this WIP port along with openblas.
(In reply to Jason W. Bacon from comment #51) Hi, > OpenBLAS 0.3.25 requires a length argument. Is 1 the right value? This is not OpenBLAS ABI releated but LAPACK ABI. DPOTRF has a "CHARACTOR*1" argument so I added '1' to tail. I did not add length because DGEQRF has no charactor argument. Please refer LAPACK reference: *DPOTRF https://www.netlib.org/lapack/explore-html/d1/d7a/group__double_p_ocomputational_ga2f55f604a6003d03b5cd4a0adcfb74d6.html *DGEQRF https://netlib.org/lapack/explore-html/df/dc5/group__variants_g_ecomputational_ga3766ea903391b5cf9008132f7440ec7b.html Also please refer /usr/local/include/lapack.h. It defines LAPACK GLOBAL macro that seems to abstract these length argument. The patch that I maked is only experimental to pass poudriere test.
(In reply to Eijiro Shibusawa from comment #52) Thanks for the followup. I am aware that it's an LAPACK API issue, and I stated so in the GCTA github issue. As GCTA is under active development, I suspect that upstream will resolve this issue soon and cut a new release. I think the experimental patches are good enough as a stop-gap, though I intend to keep an eye in the issue.
BTW, LAPACK 3.12.0 has been released. See <https://www.netlib.org/lapack/> and <https://github.com/Reference-LAPACK/lapack/releases/tag/v3.12.0>. But let’s wait for this PR to be committed, because I guess that this upgrade of Netlib will require another exp-run…
Hello Antoine, Could you please re-launch an exp-run, including the patch for GCTA?
(In reply to Thierry Thomas from comment #55) Hello, biology/gcta is a leaf port so there won't be an exp-run for it.
(In reply to Antoine Brodin from comment #56) I meant an exp-run of math/openblas, with biology/gcta patched, to see if some other ports fail.
(In reply to Thierry Thomas from comment #57) The exp-run was already done on comment #41
(In reply to Antoine Brodin from comment #58) OK, then I take this PR back, and I shall commit it ASAP.
Finally, it's here! Thank you all so much.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=84ca7effd38f7ff589ef044ad453b93d688542f6 commit 84ca7effd38f7ff589ef044ad453b93d688542f6 Author: Eijiro Shibusawa <phd_kimberlite@yahoo.co.jp> AuthorDate: 2023-12-12 18:17:39 +0000 Commit: Thierry Thomas <thierry@FreeBSD.org> CommitDate: 2023-12-12 19:03:50 +0000 math/openblas: upgrade to 0.3.25 Releases notes at <https://github.com/OpenMathLib/OpenBLAS/releases>. PR: 273219 Exp-run by: antoine@ math/openblas/Makefile | 3 ++- math/openblas/distinfo | 6 +++--- math/openblas/files/patch-c_check (gone) | 11 ----------- math/openblas/files/patch-common__arm.h | 4 ++-- math/openblas/files/patch-exports_Makefile | 4 ++-- math/openblas/files/patch-f_check (gone) | 28 ---------------------------- 6 files changed, 9 insertions(+), 47 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ab1713728d621e7b57d276ef27de37a8754e6ee0 commit ab1713728d621e7b57d276ef27de37a8754e6ee0 Author: Thierry Thomas <thierry@FreeBSD.org> AuthorDate: 2023-12-12 19:00:34 +0000 Commit: Thierry Thomas <thierry@FreeBSD.org> CommitDate: 2023-12-12 19:03:50 +0000 */*: bump PORTREVISION after the upgrade of OpenBLAS PR: 273219 biology/bolt-lmm/Makefile | 2 +- biology/gemma/Makefile | 2 +- biology/plink/Makefile | 2 +- cad/gmsh/Makefile | 2 +- editors/openoffice-4/Makefile | 2 +- editors/openoffice-devel/Makefile | 2 +- french/aster/Makefile | 2 +- games/leela-zero/Makefile | 2 +- games/naev/Makefile | 2 +- graphics/matplotplusplus/Makefile | 2 +- graphics/opencv/Makefile | 2 +- lang/julia/Makefile | 1 + math/adept/Makefile | 2 +- math/alps/Makefile | 1 + math/ambit/Makefile | 1 + math/armadillo/Makefile | 1 + math/arpack++/Makefile | 2 +- math/bcps/Makefile | 2 +- math/blaspp/Makefile | 2 +- math/blaze/Makefile | 2 +- math/bonmin/Makefile | 2 +- math/casadi/Makefile | 2 +- math/cbc/Makefile | 1 + math/ceres-solver/Makefile | 2 +- math/cgl-conic/Makefile | 2 +- math/cgl/Makefile | 1 + math/cminpack/Makefile | 2 +- math/coinmp/Makefile | 2 +- math/coinutils/Makefile | 1 + math/cosma/Makefile | 2 +- math/costa/Makefile | 2 +- math/couenne/Makefile | 2 +- math/dbcsr/Makefile | 1 + math/disco/Makefile | 2 +- math/dune-alugrid/Makefile | 2 +- math/dune-common/Makefile | 2 +- math/dune-fem/Makefile | 2 +- math/dune-geometry/Makefile | 2 +- math/dune-grid-glue/Makefile | 2 +- math/dune-grid/Makefile | 2 +- math/dune-pdelab/Makefile | 2 +- math/dune-polygongrid/Makefile | 2 +- math/dune-uggrid/Makefile | 2 +- math/dune-vtk/Makefile | 2 +- math/elemental/Makefile | 1 + math/elpa/Makefile | 2 +- math/faiss/Makefile | 2 +- math/fenics-basix/Makefile | 2 +- math/fflas-ffpack/Makefile | 1 + math/flexiblas/Makefile | 1 + math/flint2/Makefile | 2 +- math/freefem++/Makefile | 1 + math/g2o/Makefile | 2 +- math/gravity/Makefile | 2 +- math/hmat-oss/Makefile | 1 + math/hydrogen/Makefile | 2 +- math/igraph/Makefile | 2 +- math/iml/Makefile | 2 +- math/jags/Makefile | 2 +- math/lapack++/Makefile | 2 +- math/moab/Makefile | 2 +- math/ntpoly/Makefile | 2 +- math/octave-forge-ltfat/Makefile | 1 + math/octave/Makefile | 1 + math/openturns/Makefile | 2 +- math/or-tools/Makefile | 2 +- math/osi-conic/Makefile | 2 +- math/osi/Makefile | 1 + math/osiipopt/Makefile | 2 +- math/primme/Makefile | 2 +- math/py-ambit/Makefile | 1 + math/py-igraph/Makefile | 1 + math/py-numpy/Makefile | 2 +- math/py-or-tools/Makefile | 2 +- math/py-scikit-umfpack/Makefile | 2 +- math/py-scs/Makefile | 2 +- math/qposases/Makefile | 2 +- math/scalapack/Makefile | 2 +- math/scalapackfx/Makefile | 2 +- math/scs/Makefile | 1 + math/slicot/Makefile | 2 +- math/spla/Makefile | 2 +- math/suitesparse-cholmod/Makefile | 1 + math/suitesparse-config/Makefile | 1 + math/suitesparse-spqr/Makefile | 1 + math/suitesparse-umfpack/Makefile | 1 + math/sundials/Makefile | 2 +- math/symphony/Makefile | 1 + math/trlib/Makefile | 1 + misc/mxnet/Makefile | 2 +- misc/openmvg/Makefile | 2 +- misc/py-pytorch/Makefile | 1 + misc/visp/Makefile | 2 +- multimedia/opentoonz/Makefile | 2 +- science/bagel/Makefile | 2 +- science/berkeleygw/Makefile | 2 +- science/bout++/Makefile | 2 +- science/cantera/Makefile | 1 + science/chemps2/Makefile | 2 +- science/chrono/Makefile | 2 +- science/dalton/Makefile | 2 +- science/dftbplus/Makefile | 2 +- science/dftd4/Makefile | 1 + science/elk/Makefile | 2 +- science/elmerfem/Makefile | 2 +- science/erkale/Makefile | 2 +- science/fleur/Makefile | 2 +- science/frontistr/Makefile | 2 +- science/gbtolib/Makefile | 2 +- science/iboview/Makefile | 2 +- science/latte/Makefile | 2 +- science/libcint/Makefile | 1 + science/libmbd/Makefile | 2 +- science/libnegf/Makefile | 2 +- science/meep/Makefile | 1 + science/mopac/Makefile | 2 +- science/mpb/Makefile | 2 +- science/multicharge/Makefile | 2 +- science/multiwfn/Makefile | 1 + science/nlcglib/Makefile | 2 +- science/ocean/Makefile | 1 + science/opensim-core/Makefile | 2 +- science/pastix/Makefile | 1 + science/psi4/Makefile | 1 + science/py-gpaw/Makefile | 2 +- science/py-phono3py/Makefile | 2 +- science/py-pyscf/Makefile | 1 + science/py-scipy/Makefile | 1 + science/qiskit-aer/Makefile | 2 +- science/qmcpack/Makefile | 2 +- science/quantum-jet/Makefile | 2 +- science/siconos/Makefile | 2 +- science/simbody/Makefile | 2 +- science/simple-dftd3/Makefile | 1 + science/sirius/Makefile | 2 +- science/tblite/Makefile | 2 +- science/ukrmol+/Makefile | 2 +- science/xtb/Makefile | 2 +- 138 files changed, 138 insertions(+), 101 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=22df0dbcfa877e85bf5c29d7ff6808f7116cafb7 commit 22df0dbcfa877e85bf5c29d7ff6808f7116cafb7 Author: Eijiro Shibusawa <phd_kimberlite@yahoo.co.jp> AuthorDate: 2023-12-12 18:53:43 +0000 Commit: Thierry Thomas <thierry@FreeBSD.org> CommitDate: 2023-12-12 19:03:50 +0000 biology/gcta: chase the upgrade of OpenBLAS GCTA should modify the LAPACK functios calls, this is a temporary fix. See <https://github.com/jianyangqt/gcta/issues/59>. PR: 273219 Approved by: jwb@ biology/gcta/Makefile | 1 + biology/gcta/files/patch-include_Matrix.hpp (new) | 24 +++++++++++++++++++++++ biology/gcta/files/patch-include_cpu.h | 7 ++++--- biology/gcta/files/patch-main_mkl.cpp (new) | 24 +++++++++++++++++++++++ biology/gcta/files/patch-src_StatLib.cpp (new) | 19 ++++++++++++++++++ 5 files changed, 72 insertions(+), 3 deletions(-)