On 5/27/19 6:12 PM, Jeremie Courreges-Anglas wrote:
On Mon, May 27 2019, Martin Reindl <mar...@catai.org> wrote:
Am 21.05.19 um 15:34 schrieb Martin Reindl:
On Fri, May 17, 2019 at 06:45:29AM -0600, phess...@openbsd.org wrote:
http://build-failures.rhaalovely.net/aarch64/2019-05-13/math/py-scipy.log
Pick up gfortran for py-scipy on arm64.
macppc and amd64 are still happy.
-m
Index: Makefile
===================================================================
RCS file: /cvs/ports/math/py-scipy/Makefile,v
retrieving revision 1.40
diff -u -p -u -p -r1.40 Makefile
--- Makefile 1 May 2019 12:12:24 -0000 1.40
+++ Makefile 21 May 2019 13:20:10 -0000
@@ -5,7 +5,7 @@ COMMENT= maths, science and engineering
MODPY_EGG_VERSION= 1.2.1
DISTNAME= scipy-${MODPY_EGG_VERSION}
PKGNAME= py-${DISTNAME}
-REVISION= 2
+REVISION= 3
# XXX gcc 8 issue:
# ld: error: dfft_subr_6.f:(.debug_loc+0x2A7D): has non-ABS relocation
R_386_GOTOFF against symbol 'ntryh.3712'
@@ -23,8 +23,6 @@ PERMIT_PACKAGE_CDROM= Yes
WANTLIB += ${MODFORTRAN_WANTLIB} ${MODPY_WANTLIB}
WANTLIB += blas lapack m pthread ${COMPILER_LIBCXX} util
-
-COMPILER = base-clang ports-gcc base-gcc
HOMEPAGE= https://scipy.org/
Digging deeper here. This is my interpretation, please correct me if I
am wrong:
On aarch64, the current COMPILER line expands to:
- base-clang: no fortran suport, no compiler link is set up
- ports-gcc: aarch64 is not in GCC49_ARCHS, no compiler link is set up
(gcc4.9 had no fortran for aarch64 anyway)
- base-gcc: does not match on clang arch
Hah.
math/R works around this by using flang, but ports-gcc has moved from
4.9 to 8 now and gained fortran support for aarch64.
R was indeed moved to flang on aarch64, see this thread:
https://marc.info/?l=openbsd-ports&m=155732708628123&w=2
At that time I thought that gfortran failed to build R on aarch64
because of some errors, but looking at the build-failures report it
seems that the failure is indeed due to gfortran being missing:
http://build-failures.rhaalovely.net/aarch64/2019-05-04/math/R.log
checking whether we are using the GNU Fortran compiler... no
checking whether gfortran accepts -g... no
[...]
configure: error: cannot compile a simple Fortran program
So really,
ports/infrastructure/mk should also transition from GCC49 to GCC8.
Here is a quick hack to see if I am moving in the right direction (at
least this makes py-scipy on aarch64 work without the above diff).
Opinions?
Adding aarch64 to GCC49_ARCHS makes sense to me. Renaming GCC49_ARCHS
to something else can be done in another step. ok jca@
cc'ing bcallah@, pascal@, phessler@ and espie@, maybe I'm missing
others.
I started the "use flang on aarch64" work before gcc-8 was in the ports
tree. If gfortran works on aarch64 then I'm all for moving aarch64 over
to it. I can run some tests a bit later.
(Btw, the devio.us mailserver is very dead. No ETA on its revival.)
~Brian
Index: arch-defines.mk
===================================================================
RCS file: /cvs/ports/infrastructure/mk/arch-defines.mk,v
retrieving revision 1.64
diff -u -p -r1.64 arch-defines.mk
--- arch-defines.mk 11 May 2019 12:05:46 -0000 1.64
+++ arch-defines.mk 27 May 2019 18:52:04 -0000
@@ -36,7 +36,7 @@ LLD_ARCHS = aarch64 amd64 arm i386
# as well as available for PROPERTIES checks.
LLVM_ARCHS = aarch64 amd64 arm i386 mips64 mips64el powerpc sparc64
# arches where gcc4.9 exists. To be used again for modules
-GCC49_ARCHS =alpha amd64 arm hppa i386 mips64 mips64el powerpc sparc64
+GCC49_ARCHS = aarch64 alpha amd64 arm hppa i386 mips64 mips64el powerpc
sparc64
# arches where there is a C++11 compiler, either clang in base or gcc4
CXX11_ARCHS = ${CLANG_ARCHS} ${GCC49_ARCHS}
