[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