Monday, May 27, 2019

Adding aarch64 to GCC49_ARCHS (was: Re: FIX: py-scipy on arm64 [WAS: aarch64 bulk build report])

On Mon, May 27 2019, Martin Reindl <martin@catai.org> wrote:
> Am 21.05.19 um 15:34 schrieb Martin Reindl:
>> On Fri, May 17, 2019 at 06:45:29AM -0600, phessler@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.

> 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}
>

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE

No comments:

Post a Comment