Summary: | dev-lang/go [gccgo]: does not build on arm | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrius Štikonas <andrius> |
Component: | Current packages | Assignee: | William Hubbs <williamh> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jstein |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | gdb.txt |
Description
Andrius Štikonas
2017-05-17 20:26:31 UTC
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). |