Comment 1:

So here is what I think is going on (it's a little confusing).
The prerequisites are this:
 * a package, lets call it foo
 * another package, bar, that depends on foo
 * foo has file "internal_test.go" that says "package foo"
 * foo has another file "external_test.go" that says "package foo_test" that depends on bar
 * you've run go install -compiler gccgo foo (or go test -i -compiler gccgo foo)
When you run "go test -compiler gccgo foo", it first builds libfoo.a in $WORK including
internal_test.go.  When it builds the foo.test executable and it looks up the
dependencies of bar and finds the installed libfoo.a (this, I think, is the bug).
Both libfoo.a files are passed to the link command and the order varies (I presume due
to the order things come out of a hash, but I haven't verified this).
If the newly built libfoo.a comes first, it contains all needed symbols so the installed
libfoo.a is never examined by the linker and the link succeeds.  If the installed
libfoo.a comes first, it does not contain the symbols defined by internal_test.go and so
both .a files are included by the linker, leading to duplicate symbols.

Comment 2:

Labels changed: added priority-soon, gccgo, removed priority-triage.

Status changed to Accepted.

Comment 3:

Labels changed: added go1.3maybe.

Comment 4:

Labels changed: added toolbug.

Comment 5:

Labels changed: added release-none, removed go1.3maybe.

Comment 6:

Labels changed: added repo-gccgo.

Comment 7:

Hi, is Repo-Gccgo appropriate for this bug?  It's a bug in the go tool, which is part of
the go distribution...

Comment 8:

Yes, this is Repo-Main.

Labels changed: added release-go1.3maybe, repo-main, removed priority-soon, release-none, repo-gccgo.

Comment 9:

This issue was closed by revision 9f8f0a1.

Status changed to Fixed.