This is more or less upstream bug https://github.com/golang/go/issues/16906 Older versions of Go do not work with binutils 2.27 if cgo is enabled. This problem affects gcc-5.4.0 (current ~amd64) gccgo, which is based on Go 1.4.2: % go-5 version go version go1.4.2 gccgo (Gentoo 5.4.0 p1.0, pie-0.6.5) 5.4.0 linux/amd64 when building go-1.7.4 with USE=gccgo set, it fails with the error message from that upstream bug: >>> Compiling source in /var/tmp/portage/dev-lang/go-1.7.4/work/go ... * GOROOT_BOOTSTRAP is /var/tmp/portage/dev-lang/go-1.7.4/work/go-linux-amd64-bootstrap ##### Building Go bootstrap tool. cmd/dist # _/var/tmp/portage/dev-lang/go-1.7.4/work/go/src/cmd/dist cannot load DWARF output from $WORK/_/var/tmp/portage/dev-lang/go-1.7.4/work/go/src/cmd/dist/_obj//_cgo_.o: decoding dwarf section info at offset 0x4: unsupported version 0 USE=-gccgo is not affected, and if I temporarily switch back to binutils-2.26.1 the problem goes away. I'm not 100% sure why USE=-gccgo is not affected, since if I build a library that uses cgo (I tested with github.com/mattn/go-sqlite3) with the bootstrap Go compiler it fails the same way. I suspect the Go bootstrap utility is the only thing built using the bootstrap Go compiler, and that utility only uses cgo when compiled with gccgo (further explained below). This is really a bug in the bootstrap Go compiler, so maybe this should be filed against gcc. But I'm filing this against dev-lang/go because it might want to depend on a working Go compiler (although that's not trivial since this is triggered by the selected version of binutils). Upstream suggests setting CGO_ENABLED=0 when running make.bash. But if I make that change to the ebuild, it fails differently: >>> Compiling source in /var/tmp/portage/dev-lang/go-1.7.4/work/go ... * GOROOT_BOOTSTRAP is /var/tmp/portage/dev-lang/go-1.7.4/work/go-linux-amd64-bootstrap ##### Building Go bootstrap tool. cmd/dist # _/var/tmp/portage/dev-lang/go-1.7.4/work/go/src/cmd/dist cmd/dist/build.go:130:6: error: reference to undefined name ‘cansse2’ if cansse2() { ^ cmd/dist/util.go:488:3: error: reference to undefined name ‘useVFPv1’ useVFPv1() // might fail with SIGILL ^ cmd/dist/util.go:490:3: error: reference to undefined name ‘useVFPv3’ useVFPv3() // might fail with SIGILL ^ Looking at Go's source, it looks like building using gccgo with cgo disabled is not possible. There are two possible definitions for these functions: one set in src/cmd/dist/util_gc.go and src/cmd/dist/vfp_default.s that is used when not using gccgo, and one in src/cmd/dist/util_gccgo.go that is only used when using gccgo. The latter set uses cgo. The former set uses assembly, which I'm guessing gccgo does not support. So I believe using gccgo from gcc-5.4.0 or lower with binutils-2.27 or higher is not possible. gcc 6's gccgo might work (I haven't tested this).
*** Bug 603178 has been marked as a duplicate of this bug. ***
Based on what I see in the upstream documentation, gcc-6 will probably be needed if you want to bootstrap with gccgo. Currently, I recommend not using the gccgo use flag to bootstrap. https://golang.org/doc/install/gccgo
> Based on what I see in the upstream documentation, gcc-6 will probably > be needed if you want to bootstrap with gccgo. gcc-6 doesn't change anything for me, dev-lang/go with USE=gccgo continues to be broken: # gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/6.3.0/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-6.3.0/work/gcc-6.3.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/6.3.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/6.3.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/6.3.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/6.3.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/include/g++-v6 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/6.3.0/python --enable-languages=c,c++,go --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 6.3.0 p1.0' --disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --with-multilib-list=m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --enable-libmpx --enable-vtable-verify --enable-libvtv --disable-libquadmath --enable-lto --without-isl --enable-libsanitizer --disable-default-pie --disable-default-ssp Thread model: posix gcc version 6.3.0 (Gentoo 6.3.0 p1.0) >>> Emerging (1 of 1) dev-lang/go-1.7.4::gentoo * GOROOT_BOOTSTRAP is /var/tmp/portage/dev-lang/go-1.7.4/work/go-linux-amd64-bootstrap ##### Building Go bootstrap tool. cmd/dist # _/var/tmp/portage/dev-lang/go-1.7.4/work/go/src/cmd/dist cannot load DWARF output from $WORK/_/var/tmp/portage/dev-lang/go-1.7.4/work/go/src/cmd/dist/_obj//_cgo_.o: decoding dwarf section info at offset 0x4: unsupported version 0
I'm not sure I fully understand the status here. Since we now have default stable binutils 2.28.1, and since gcc 6 is about to be stabilized - what works and what doesnt?
Should be fixed as long as gcc-6 (or newer) is selected, but the current stable binutils (2.28.1) breaks dev-lang/go[gccgo] without >=gcc-6. Marking gcc-6 stable makes this bug more fixed :) Using sys-devel/gcc-6.4.0 and sys-devel/binutils-2.29.1, dev-lang/go-1.9 does build for me with USE=gccgo. That's the expected result: gcc-6 has a sufficiently recent version of Go. comment #3 can be explained by bug #606440: dev-lang/go-1.7.4 was using go-5 (the Go binary from gcc-5) to bootstrap, even when "gcc" was configured to be gcc 6. Current versions of the ebuild follow the selected gcc's major version.
(In reply to Marien Zwart from comment #5) > Marking gcc-6 stable makes this bug more fixed :) Excellent & thanks for the explanation!
I guess we can close this now that <2.29.1 is masked. Re-open if you disagree.
