Bug 228011

Summary: math/openblas: switch to flang
Product: Ports & Packages Reporter: robert.ayrapetyan
Component: Individual Port(s)Assignee: freebsd-ports-bugs (Nobody) <ports-bugs>
Status: Open ---    
Severity: Affects Many People CC: arrowd, diizzy, michael.osipov, phd_kimberlite, rene, rhurlin, sergey, thierry, void
Priority: --- Flags: phd_kimberlite: maintainer-feedback+
Version: Latest   
Hardware: amd64   
OS: Any   
Attachments:
Description Flags
necessary changes for switching to flang
none
poudriere log for a patched port
none
necessary changes for switching to flang
none
poudriere log for a patched port
none
proper handling of non-supported archs none

Description robert.ayrapetyan 2018-05-06 06:11:20 UTC
Created attachment 193076 [details]
necessary changes for switching to flang

There are lot of known problems with gfortran when clang is involved, e.g.:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196862

This patch switches to using flang compiler (on amd64 only) and resolves gcc linking issues.

Note:
- deleted file "files/patch-exports+Makefile" (backward compatibility checked on gfortran builds)
- patched "Makefile" contains a "ditry" arch check, I believe it's the best available option now until "flang" will be set by default for all amd64 ports in fortran.mk.
Comment 1 robert.ayrapetyan 2018-05-06 22:06:51 UTC
Created attachment 193122 [details]
poudriere log for a patched port
Comment 2 Yuri Victorovich freebsd_committer freebsd_triage 2018-05-07 00:16:35 UTC
There are 2 issues with this patch:
1. The correct way to do this is using the port option FLANG, see math/R how this is done there. Please resubmit the patch doing this 
2. Some people might disagree with this, not sure. This adds a certain level of complexity.

Also, for this all ports that depend on lapack should probably be rebuilt and retested.
Comment 3 robert.ayrapetyan 2018-05-07 06:41:26 UTC
Created attachment 193137 [details]
necessary changes for switching to flang

A less-destructive switch to flang (OPTION).
Comment 4 robert.ayrapetyan 2018-05-07 06:41:50 UTC
Created attachment 193138 [details]
poudriere log for a patched port
Comment 5 robert.ayrapetyan 2018-05-07 22:24:01 UTC
Created attachment 193167 [details]
proper handling of non-supported archs
Comment 6 Dmitry Marakasov freebsd_committer freebsd_triage 2021-02-16 02:20:21 UTC
The patch no longer applies. I'm afraid it needs to be updated.
Comment 7 Gleb Popov freebsd_committer freebsd_triage 2021-03-20 08:06:11 UTC
There is no reason to refresh the patch yet.

The thing that is now called "flang" is a completely different project than the one from back then in 2018. At the moment, the new Flang isn't able to compile anything, so it is impossible to switch to it. Once the new Flang matures, it will be included in the devel/llvmXX port (I presume), and then we will be able to make a switch.
Comment 8 Rene Ladan freebsd_committer freebsd_triage 2022-09-30 20:12:00 UTC
devel/flang expired today.
Comment 9 Gleb Popov freebsd_committer freebsd_triage 2022-10-01 04:22:28 UTC
(In reply to Rene Ladan from comment #8)
Hopefully, at some point the devel/llvmXY port will eventually provide a new flang suitable to be hooked into USES=fortran
Comment 10 Thierry Thomas freebsd_committer freebsd_triage 2022-10-01 08:35:23 UTC
(In reply to Gleb Popov from comment #9)

LFortran seems very interesting: see <https://lfortran.org/>.
Comment 11 Daniel Engberg freebsd_committer freebsd_triage 2022-11-09 17:32:01 UTC
Looking at other repos they use GCC 11 (or 12) with gfortran, is that still troublesome?
Comment 12 Thierry Thomas freebsd_committer freebsd_triage 2022-11-09 18:51:50 UTC
I’d like to add at least one alternative in Mk/Uses/fortran.mk, maybe LFortran or flang-new, but they are not yet ready.
Comment 13 void 2023-03-31 14:19:32 UTC
Does openblas now require FLANG as openblas fails to build in poudriere on a system with the FLANG option disabled for LLVM. (arm64)

openblas options:

00:00:01] ---Begin OPTIONS List---
[00:00:01] ===> The following configuration options are available for openblas-0.3.20,1:
[00:00:01]      AVX=on: Support Advanced Vector Extensions (AVX)
[00:00:01]      AVX2=on: Support Advanced Vector Extensions 2 (AVX2)
[00:00:01]      DYNAMIC_ARCH=off: Optimize for multiple CPU types, otherwise for this CPU
[00:00:01]      INTERFACE64=on: Use 8 byte integers on 64-bit architectures
[00:00:01]      OPENMP=on: Use OpenMP for threading
[00:00:01] ===> Use 'make config' to modify these settings

build failure:

[00:00:11] =======================<phase: build          >============================
[00:00:11] ===== env: NO_DEPENDS=yes USER=root UID=0 GID=0
[00:00:11] ===>  Building for openblas-0.3.20,1
[00:00:11] gmake[1]: Entering directory '/wrkdirs/usr/ports/math/openblas/work/OpenBLAS-0.3.20'
[00:00:11] getarch.c:1553:2: error: "The TARGET specified on the command line or in Makefile.rule is not supported. Please choose a target from TargetList.txt"
[00:00:11] #error "The TARGET specified on the command line or in Makefile.rule is not supported. Please choose a target from TargetList.txt"
[00:00:11]  ^
[00:00:11] 1 error generated.
[00:00:11] gmake[1]: *** [Makefile.prebuild:74: getarch] Error 1
[00:00:11] Makefile.system:283: Makefile.conf: No such file or directory
[00:00:11] gmake[1]: *** No rule to make target 'Makefile.conf'.  Stop.
[00:00:11] gmake[1]: Leaving directory '/wrkdirs/usr/ports/math/openblas/work/OpenBLAS-0.3.20'
[00:00:11] ===> Compilation failed unexpectedly.
[00:00:11] Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
[00:00:11] the maintainer.
[00:00:11] *** Error code 1
[00:00:11] 
[00:00:11] Stop.
[00:00:11] make: stopped in /usr/ports/math/openblas
[00:00:11] =>> Cleaning up wrkdir
[00:00:11] ===>  Cleaning for openblas-0.3.20,1
[00:00:11] build of math/openblas | openblas-0.3.20,1 ended at Fri Mar 31 04:17:59 BST 2023
[00:00:11] build time: 00:00:11
Comment 14 void 2023-03-31 14:20:13 UTC
sorry that should read AMD64
Comment 15 void 2023-04-01 12:26:07 UTC
(In reply to void from comment #14)

ignore me, the issue was caused by having cputype defined for my cpu inn make.conf