<p dir="auto">by <strong><a href="mailto:calvin.walton@kepstin.ca">calvin.walton@kepstin.ca</a></strong>:</p>
<pre class="notranslate">What steps will reproduce the problem?
1. Attempt to build go (6g) with a gcc version which is different from what any of the
developers use, or with different versions of system libraries or tools

What is the expected output?
The go compiler successfully builds for the user who wants to use it, possibly printing
out a couple of new warning messages.

What do you see instead?
The go compiler fails to build, with a silly error message like

cc1: warnings being treated as errors
y.tab.c:5203:9: error: passing argument 1 of 'yyerror' discards qualifiers from pointer
target type
/home/cwalton/Development/go/src/cmd/gc/go.h:1148:6: note: expected 'char *' but
argument is of type 'const char *'

frustrating someone who just wanted to try a new programming language.

Which compiler are you using (5g, 6g, 8g, gccgo)?
Compiling 6g from a mercurial checkout of the release branch as described on the
"getting started" page

Which operating system are you using?
Exherbo Linux with gcc 4.5.3 and bison 2.5

Which revision are you using?  (hg identify)
9d7967223815 (release-branch.r57) release/release.r57.2

Please provide any additional information below.
I "fixed" the issue by deleting "-Werror" from quietgcc.bash to get
a successful build which passed all tests and operates correctly.</pre>
<pre class="notranslate">discussion: <a href="http://golang.org/cl/5822049/" rel="nofollow">http://golang.org/cl/5822049/</a>

If we support this feature, we don't need to support handing of any relocations, linking
gcc compiled object files.

Pros: able to link in C++ in cgo; remove a lot of code in our linker.
Cons: dependent on gcc for linking cgo programs, even if I could make all gcc compiled
object files available as .syso files.</pre>