Build log: * Package: dev-lang/go-1.8.1 * Repository: gentoo * Maintainer: williamh@gentoo.org * USE: arm elibc_glibc gccgo kernel_linux userland_GNU * FEATURES: preserve-libs sandbox userpriv usersandbox >>> Unpacking source... >>> Unpacking go1.8.1.src.tar.gz to /var/tmp/portage/dev-lang/go-1.8.1/work >>> Source unpacked in /var/tmp/portage/dev-lang/go-1.8.1/work >>> Preparing source in /var/tmp/portage/dev-lang/go-1.8.1/work/go ... >>> Source prepared. >>> Configuring source in /var/tmp/portage/dev-lang/go-1.8.1/work/go ... >>> Source configured. >>> Compiling source in /var/tmp/portage/dev-lang/go-1.8.1/work/go ... * GOROOT_BOOTSTRAP is /var/tmp/portage/dev-lang/go-1.8.1/work/go-linux-arm-bootstrap ##### Building Go bootstrap tool. cmd/dist No error, nothing, just forever stuck. I'm using gcc 6.3.0 on armv7a (Odroid-U2). Reproducible: Always
Can you provide more details? Is the CPU at 100%? RAM full? Which processes are running? Please attach the logfiles https://wiki.gentoo.org/wiki/Bugzilla/Bug_report_guide#Problems_at_build_time
Odroid U2 has four cores. Two threads are used 100% by /var/tmp/portage/dev-lang/go-1.8.1/work/go-linux-arm-bootstrap/bin/go build -o cmd/dist/dist ./cmd/dist I've already pasted build.log in my first post. I can try to attach gdb output, but I need to recompile GCC with debug symbols then.
(In reply to Andrius Štikonas from comment #2) > Odroid U2 has four cores. Two threads are used 100% by > > /var/tmp/portage/dev-lang/go-1.8.1/work/go-linux-arm-bootstrap/bin/go build > -o cmd/dist/dist ./cmd/dist > > I've already pasted build.log in my first post. I can try to attach gdb > output, but I need to recompile GCC with debug symbols then. I don't see any problems with RAM usage. Everything seems fine. It's just that go-6 binary is stuck. The very first command in compilation process does not finish.
(gdb) backtrace #0 0xb618950c in syscall () from /lib/libc.so.6 #1 0xb6793764 in runtime_futexsleep (addr=0xb6ea9aa0 <runtime_m0+96>, val=0, ns=<optimized out>) at /var/tmp/portage/sys-devel/gcc-6.3.0/work/gcc-6.3.0/libgo/runtime/thread-linux.c:47 #2 0xb67935b8 in runtime_notesleep (n=0xb6ea9aa0 <runtime_m0+96>) at /var/tmp/portage/sys-devel/gcc-6.3.0/work/gcc-6.3.0/libgo/runtime/lock_futex.c:137 #3 0xb679d07c in stopm () at /var/tmp/portage/sys-devel/gcc-6.3.0/work/gcc-6.3.0/libgo/runtime/proc.c:1458 #4 0xb679f284 in findrunnable () at /var/tmp/portage/sys-devel/gcc-6.3.0/work/gcc-6.3.0/libgo/runtime/proc.c:1764 #5 schedule () at /var/tmp/portage/sys-devel/gcc-6.3.0/work/gcc-6.3.0/libgo/runtime/proc.c:1847 #6 0xb679fcf0 in runtime_mstart (mp=<optimized out>) at /var/tmp/portage/sys-devel/gcc-6.3.0/work/gcc-6.3.0/libgo/runtime/proc.c:1076 #7 0x0001a614 in main (argc=5, argv=0xbefd3604) at /var/tmp/portage/sys-devel/gcc-6.3.0/work/gcc-6.3.0/libgo/runtime/go-main.c:55 #8 0xb60d4578 in __libc_start_main () from /lib/libc.so.6 #9 0x0001a65c in _start () Backtrace stopped: previous frame identical to this frame (corrupt stack?)
I have gcc hardened 5.4.0-r3 on amd64 and the executable go-5 segfaults when called (it is used to build go[gccgo])
(In reply to Alessandro Barbieri from comment #5) > I have gcc hardened 5.4.0-r3 on amd64 and the executable go-5 segfaults when > called (it is used to build go[gccgo]) I suspect that's a different problem. Both go-5 and go-6 work fine for me on non-hardened amd64.
Created attachment 473182 [details] gdb.txt trace
This is fixed in go 1.13.*. We are no longer using gccgo to bootstrap go.
(In reply to William Hubbs from comment #8) > We are no longer using gccgo to bootstrap go. That's a bit unfortunate... But oh well. Building with gccgo ensured that there is no recursive backdoor in the binary. It would have been nicer if go-bootstrap was a version that is buildable with gcc (I think it was version 1.4).
