[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3

ro at CeBiTec dot Uni-Bielefeld.DE gcc-bugzilla@gcc.gnu.org
Tue Aug 29 13:55:00 GMT 2017


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926

--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #16 from Dennis Clarke <dclarke at blastwave dot org> ---
> This is excellent follow up and it looks like GNU binutils must be around
> somewhere on the system for "Go" to build.  Also, I always run "gmake -k check"

Indeed: the documentation may not be clear enough about this, though.

> for the testsuite and not sure why it would look otherwise.  

You often see something like

make[4]: [Makefile:3354: check-am] Error 2 (ignored)

when make -k is used, and I missed that '(ignored)' part in your make
check output fragment, that's all.

> Here is the diff on 7.2.0 gcc/config/sparc/sparc.c based on your patch :

Thanks.  Before trying a backport, we probably should go for the
different solution Richard suggested, though.

> I do have GNU objcopy laying about also : 
>
> v9_7++ $ /usr/local/bin/gobjcopy --version 
> GNU objcopy (GNU Binutils) 2.23.1
> Copyright 2012 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) any later version.
> This program has absolutely no warranty.

This won't help right now: libgo's configure will only look for objcopy
(or sparc64-sun-solaris2.10-objcopy in your case) and doesn't know about
gobjcopy.

AFAICS toplevel configure checks for the g-prefixed tools and passes the
result to gcc/configure which heeds them, while libgo/configure does
not.

Probably an issue for a separate libgo bug report.

        Rainer


More information about the Gcc-bugs mailing list