../../../libgo/go/internal/cpu/cpu.go:138:2: error: reference to undefined name 'doinit' 138 | doinit() | ^ make[4]: Leaving directory '/builddir/build/BUILD/gcc-9.0.0-20190119/obj-armv7hl-redhat-linux-gnueabi/armv7hl-redhat-linux-gnueabi/libgo' make[4]: *** [Makefile:2833: internal/cpu.lo] Error 1 make[3]: *** [Makefile:2231: all-recursive] Error 1 make[3]: Leaving directory '/builddir/build/BUILD/gcc-9.0.0-20190119/obj-armv7hl-redhat-linux-gnueabi/armv7hl-redhat-linux-gnueabi/libgo' make[2]: Leaving directory '/builddir/build/BUILD/gcc-9.0.0-20190119/obj-armv7hl-redhat-linux-gnueabi/armv7hl-redhat-linux-gnueabi/libgo' make[2]: *** [Makefile:1156: all] Error 2 make[1]: *** [Makefile:20894: all-target-libgo] Error 2 make[1]: *** Waiting for unfinished jobs.... No idea why, there is cpu_no_init.go with // +build !386 // +build !amd64 // +build !amd64p32 // +build !arm64 // +build !ppc64 // +build !ppc64le // +build !s390x
This is likely fixed by https://golang.org/cl/158717.
Will try that. That said, I don't understand why cpu_no_init.go isn't used in that case. Inthe build log I see /usr/bin/mkdir -p internal; files=`echo ../../../libgo/go/internal/cpu/cpu.go cpugen.go | sed -e 's/[^ ]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/sh ./libtool --tag GO --mode=compile /builddir/build/BUILD/gcc-9.0.0-20190119/obj-armv7hl-redhat-linux-gnueabi/./gcc/gccgo -B/builddir/build/BUILD/gcc-9.0.0-20190119/obj-armv7hl-redhat-linux-gnueabi/./gcc/ -B/usr/armv7hl-redhat-linux-gnueabi/bin/ -B/usr/armv7hl-redhat-linux-gnueabi/lib/ -isystem /usr/armv7hl-redhat-linux-gnueabi/include -isystem /usr/armv7hl-redhat-linux-gnueabi/sys-include -O2 -g -I . -c -fgo-pkgpath=`echo internal/cpu.lo | sed -e 's/.lo$//'` -o internal/cpu.lo $files but if I run by hand (on x86_64-linux): ../../../libgo/match.sh --goarch=arm --goos=linux --srcdir=../../../libgo/go/internal/cpu --extrafiles="cpugen.go" ../../../libgo/go/internal/cpu/cpu.go ../../../libgo/go/internal/cpu/cpu_no_init.go cpugen.go
Oops, ignore the cpu_no_init.go related comments, I was looking at my trunk checkout apparently before r268084, while the failed build was with that change which added +build !arm in there. That explains it.
The #c2 change looks good to me, allowed armv7hl to bootstrap and compared to 8.2.1 from a week ago the libgo/gotools difference is -FAIL: io -FAIL: log +FAIL: fmt +FAIL: go/constant +FAIL: html/template +FAIL: math/big +FAIL: net/rpc FAIL: runtime -FAIL: os/signal FAIL: runtime/pprof +FAIL: sync FAIL: sync/atomic +FAIL: text/template +FAIL: text/template/parse and FAIL: go test runtime +FAIL: go test misc/cgo/test FAIL: TestEarlySignalHandler FAIL: go test misc/cgo/testcarchive +FAIL: TestVet +FAIL: go test cmd/vet s390x libgo is in much worse shape it seems.
Author: ian Date: Tue Jan 22 00:06:44 2019 New Revision: 268131 URL: https://gcc.gnu.org/viewcvs?rev=268131&root=gcc&view=rev Log: PR go/88927 runtime, internal/cpu: fix build for ARM GNU/Linux Was failing with ../../../libgo/go/internal/cpu/cpu.go:138:2: error: reference to undefined name 'doinit' 138 | doinit() | ^ Fix it by adding in Go 1.12 internal/cpu/cpu_arm.go, and the code in runtime that initializes the values. Fixes https://gcc.gnu.org/PR88927. Reviewed-on: https://go-review.googlesource.com/c/158717 Added: trunk/libgo/go/internal/cpu/cpu_arm.go Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/runtime/os_linux_arm.go
The build problem is fixed, leaving the test failures for another day.