* Package: dev-lang/go-1.8.1
* Repository: gentoo
* Maintainer: email@example.com
* 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.
No error, nothing, just forever stuck. I'm using gcc 6.3.0 on armv7a (Odroid-U2).
Can you provide more details? Is the CPU at 100%? RAM full? Which processes are running?
Please attach the logfiles
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.
#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]
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).