Opened 17 months ago
Closed 8 months ago
#58832 closed defect (fixed)
OpenBLAS @0.3.7: build error when build_arch != host arch: ../kernel/x86/amax.S:64:2: error: ../kernel/x86/amax.S:instruction requires: Not 64-bit mode
Reported by: | kencu (Ken) | Owned by: | NicosPavlov |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | lion snowleopard | Cc: | michaelld (Michael Dickens), SlaunchaMan (Jeff Kelley), fvaccari, mojca (Mojca Miklavec), cooljeanius (Eric Gallager) |
Port: | openblas |
Description
Something not working right with the openblas update - this is on 10.7.5:
/opt/local/bin/clang-mp-5.0 -c -O3 -DMAX_STACK_ALLOC=2048 -DEXPRECISION -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DNO_AVX -DNO_AVX512 -DSMP_SERVER -DMAX_CPU_NUMBER=2 -DMAX_PARALLEL_NUMBER=1 -DVERSION=\"1\" -DASMNAME=_samin_k -DASMFNAME=_samin_k_ -DNAME=samin_k_ -DCNAME=samin_k -DCHAR_NAME=\"samin_k_\" -DCHAR_CNAME=\"samin_k\" -DNO_AFFINITY -I.. -UDOUBLE -UCOMPLEX -UCOMPLEX -UDOUBLE -DUSE_ABS -DUSE_MIN ../kernel/x86/amax.S -o samin_k.o ../kernel/x86/amax.S:64:2: error: ../kernel/x86/amax.S:instruction requires: Not 64-bit mode pushl %esi ^ ../kernel/x86/amax.S:65:2: error: instruction requires: Not 64-bit mode pushl %ebx ^ ../kernel/x86/amax.S:311:2: error: instruction requires: Not 64-bit mode popl %ebx ^ ../kernel/x86/amax.S:312:2: error: instruction requires: Not 64-bit mode popl %esi ^ 64:2: error: instruction requires: Not 64-bit mode pushl %esi ^ ../kernel/x86/amax.S:65:2: error: instruction requires: Not 64-bit mode pushl %ebx ^ ../kernel/x86/amax.S:311:2: error: instruction requires: Not 64-bit mode popl %ebx ^ ../kernel/x86/amax.S:312:2: error: instruction requires: Not 64-bit mode popl %esi ^ make[1]: *** [samin_k.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [samax_k.o] Error 1 make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_OpenBLAS/OpenBLAS/work/OpenBLAS-0.3.7/kernel' make: *** [libs] Error 1
Attachments (2)
Change History (25)
Changed 17 months ago by kencu (Ken)
Attachment: | openblas-10.7.5-fail-gcc9.log added |
---|
comment:1 Changed 17 months ago by kencu (Ken)
comment:2 Changed 17 months ago by kencu (Ken)
best I can figure at present, it seems to be trying to build the 32bit version of amax.S
when it is building the 64bit library on this machine, instead of building the 64bit version.
Changed 17 months ago by kencu (Ken)
Attachment: | openblas-fail-1068.log added |
---|
comment:4 Changed 17 months ago by kencu (Ken)
Keywords: | snowleopard added |
---|
comment:5 Changed 17 months ago by kencu (Ken)
comment:6 follow-up: 10 Changed 17 months ago by jmroot (Joshua Root)
Could be doing something silly like using uname -m
to determine the arch?
comment:7 Changed 17 months ago by kencu (Ken)
for now, I pegged openblas at OpenBLAS @0.3.6_1
until I get some time to sort this out.
comment:8 Changed 17 months ago by kencu (Ken)
maybe we need to look at this area in the Portfile:
if {${build_arch} eq "x86_64" || ${build_arch} eq "ppc64"} { puts $makeINC "BINARY = 64" } else { puts $makeINC "BINARY = 32" }
comment:9 Changed 17 months ago by rmottola (Riccardo)
I encountered exactly the same error on 10.7 (obviously 64bit)
comment:10 Changed 16 months ago by kencu (Ken)
Replying to jmroot:
Could be doing something silly like using
uname -m
to determine the arch?
Indeed, clever sir, that is just exactly what it is doing:
# If ARCH is not set, we use the host system's architecture. ifndef ARCH ARCH := $(shell uname -m) endif
and fixing that by specifically hacking in a setting for ARCH
to x86_64
:
if { ${os.major} <= 10 } { puts $makeINC "NO_AVX2 = 1" + puts $makeINC "ARCH = x86_64" }
produces the expected happiness:
$ port -v installed openblas The following ports are currently installed: OpenBLAS @0.3.6_1+gcc8+lapack+native platform='darwin 10' archs='x86_64' date='2019-05-26T18:25:37-0700' OpenBLAS @0.3.7_0+gcc8+lapack+native (active) platform='darwin 10' archs='x86_64' date='2019-10-02T19:52:08-0700'
Looks like it came in here <https://github.com/xianyi/OpenBLAS/pull/2110> and it may already be fixed in git master <https://github.com/xianyi/OpenBLAS/issues/2231>, so perhaps I'll just try that instead of messing about with the whole build.
comment:11 Changed 16 months ago by kencu (Ken)
Summary: | OpenBLAS @0.3.7: ../kernel/x86/amax.S:64:2: error: ../kernel/x86/amax.S:instruction requires: Not 64-bit mode → OpenBLAS @0.3.7: build error when build_arch != host arch: ../kernel/x86/amax.S:64:2: error: ../kernel/x86/amax.S:instruction requires: Not 64-bit mode |
---|
comment:12 Changed 16 months ago by kencu (Ken)
So yes, this issue is already fixed in the current OpenBLAS-devel
port, in which OpenBLAS has more cleverness about ARCH
setting.
comment:13 Changed 15 months ago by SlaunchaMan (Jeff Kelley)
Cc: | SlaunchaMan added |
---|
comment:14 Changed 15 months ago by fvaccari
Cc: | fvaccari added |
---|
comment:15 Changed 15 months ago by mojca (Mojca Miklavec)
Cc: | mojca added |
---|
comment:16 Changed 15 months ago by fvaccari
I just tested on 10.6.8 that after adjusting
puts $makeINC "ARCH = x86_64"
another error pops up later in the compilation:
/opt/local/bin/clang-mp-9.0 -c -O3 -DMAX_STACK_ALLOC=2048 -DEXPRECISION -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DNO_AVX2 -DNO_AVX512 -DSMP_SERVER -DMAX_CPU_NUMBER=2 -DMAX_PARALLEL_NUMBER=1 -DVERSION=\"1\" -DASMNAME=_ssymv_U -DASMFNAME=_ssymv_U_ -DNAME=ssymv_U_ -DCNAME=ssymv_U -DCHAR_NAME=\"ssymv_U_\" -DCHAR_CNAME=\"ssymv_U\" -DNO_AFFINITY -I.. -UDOUBLE -UCOMPLEX -UCOMPLEX -UDOUBLE -ULOWER ../kernel/x86_64/symv_U_sse.S -o ssymv_U.o ../kernel/x86_64/symv_U_sse.S:425:2: error: 32-bit absolute addressing is not supported in 64-bit mode PREFETCH PREFETCHSIZE(%rbx) ^ ../kernel/x86_64/symv_U_sse.S:444:2: error: 32-bit absolute addressing is not supported in 64-bit mode PREFETCH PREFETCHSIZE(%r13) ^ ../kernel/x86_64/symv_U_sse.S:469:2: error: 32-bit absolute addressing is not supported in 64-bit mode PREFETCH PREFETCHSIZE(%rbx, %rcx, 1) ^ ../kernel/x86_64/symv_U_sse.S:510:2: error: 32-bit absolute addressing is not supported in 64-bit mode PREFETCH PREFETCHSIZE(%rbp) ^ ../kernel/x86_64/symv_U_sse.S:529:2: error: 32-bit absolute addressing is not supported in 64-bit mode PREFETCHW PREFETCHSIZE(%r14) ^ ../kernel/x86_64/symv_U_sse.S:554:2: error: 32-bit absolute addressing is not supported in 64-bit mode PREFETCH PREFETCHSIZE(%rbp, %rcx, 1) ^ make[1]: *** [ssymv_U.o] Error 1 make[1]: *** Waiting for unfinished jobs....
which actually points to ticket #58528
comment:17 Changed 15 months ago by kencu (Ken)
Yes, true. I actually have this all sorted out, but just have been too distracted with all the other things going on.
The YONAH processor specified in the Portfile will not work on any 64bit OS, as YONAH is 32 bit only.
So if I manually change the processor to CORE2, or let the software work out the processor, it builds.
So -- this was a bug in OpenBLAS, and then our forcing YONAH is just not going to work. I have a fancier fix coming, using sysctl
and testing for a 64-bit capable processor (and if so, forcing CORE2) but in truth, recreating all the OpenBLAS logic to sort out the processor in Portfile logic is a bit of a pain.
comment:18 Changed 15 months ago by rmottola (Riccardo)
I read the portfile and it says:
#OS 10.7-10.11 supports down to iMac 7,1, with Intel Core 2 Duo architecture #OS 10.12-13 supports down to iMac 10,1, with Intel Core 2 Duo architecture if {${os.major} >= 11 && ${os.major} <= 17} { set blas_arch "CORE2" }
So, it appears that the CPU is set correctly for 10.7 !
10.6 is:
#OS 10.6 supports down to Intel Core Solo architecture if {${os.major} == 10} { set blas_arch "YONAH" }
for 10.5 we have:
#Define target based on version of OS #OS 10.5 supports down to Intel Core Solo (Intel) or PowerPC G4 if {${os.major} == 9} { if {${os.arch} eq "i386" || [variant_isset universal]} { set blas_arch "YONAH" } else { set blas_arch "PPCG4" } }
since it is setting "down to" if you are correct that CORE2 is required, it is wrong for 10.6 and 10.5 when in universal mode!
But... why does it fail even on 10.7 with that error, I don't fully understand.
comment:19 Changed 15 months ago by kencu (Ken)
There are two different errors. See also #58528.
#58528 is fixed in OpenBLAS-devel, I believe (should be, as I saw that commit roll by a while ago), but this one is our bug, and will never be fixed until we fix it.
Here is my WIP <https://github.com/kencu/macports-ports/commit/462e990eb0208187c5abdcfa29d9507945106a81>, not quite done yet.
comment:20 Changed 14 months ago by rmottola (Riccardo)
I just tried openblas-devel on 10.7 and it appears to work. on 10.5 and 10.6 I did not try yet... but I am stll puzzled by YONAH vs CORE2 and forcing it.
comment:21 Changed 14 months ago by kencu (Ken)
we are forcing YONAH on systems that are sometimes 64bit, and it breaks in a 64bit build. We have to force CORE2 on 64bit systems instead.
The trick is to solve this generally for the buildbots.
I have been waiting for a new openblas release, as the other error was in openblas itself, and is fixed in openblas-devel, as you noticed.
comment:22 Changed 14 months ago by cooljeanius (Eric Gallager)
Cc: | cooljeanius added |
---|
comment:23 Changed 8 months ago by kencu (Ken)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I have helpfully downloaded the prebuilt binary from the buildbot. However, it appears I still can't build openblas myself on this machine. Always a bit hard to figure those kinds of errors out...