This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3
- From: "dclarke at blastwave dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 29 Aug 2017 21:53:27 +0000
- Subject: [Bug bootstrap/81926] go/parse.o differs between stage2 and stage3
- Auto-submitted: auto-generated
- References: <bug-81926-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #20 from Dennis Clarke <dclarke at blastwave dot org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #17)
> > --- Comment #16 from Dennis Clarke <dclarke at blastwave dot org> ---
> > This is excellent follow up ...
> > 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.
Please see my question below.
>
> > 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.
>
yikes ... however see info below.
> 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
Just a bit of info and a question.
info : I have set the env var OBJCOPY=/usr/local/bin/gobjcopy and
also set env var OBJDUMP=/usr/local/bin/gobjdump where both
those tools exist and are from binutils 2.23.1
ques : Richard Bierner had said earlier "I'd rather do that where the
assemby_start debug hook is called instead..." however I already
applied Rainer's patch to gcc/config/sparc/sparc.c and am running
a stage3 bootstrap now. Should that change have been done elsewhere
other than in a sparc specific target related source?