https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #20 from Dennis Clarke <dclarke at blastwave dot org> ---
(In reply to r...@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?
