cmd/go: go test -x -compiler gccgo launchpad.net/juju-core/cmd fails to link test binary intermittently

[mwhudson]

What steps will reproduce the problem?

Running "go test -x -compiler gccgo launchpad.net/juju-core/cmd" fails
intermittently (roughly 50% of the time) with linker errors.

What is the expected output?

ok      launchpad.net/juju-core/cmd 1.712s


What do you see instead?

Pages of errors like:

/tmp/go-build183489760/launchpad.net/juju-core/cmd/_test/launchpad.net/juju-core/libcmd.a(cmd.o):(.rodata.__go_tdn_launchpad.net_juju_core_cmd.Command+0x0):
multiple definition of `__go_tdn_launchpad.net_juju_core_cmd.Command'
/home/mwhudson/goplay/pkg/gccgo_linux_amd64/launchpad.net/juju-core/libcmd.a(cmd.o):(.rodata.__go_tdn_launchpad.net_juju_core_cmd.Command+0x0):
first defined here


Which compiler are you using (5g, 6g, 8g, gccgo)?

gccgo (4.8 and tip)

Which operating system are you using?

Linux, Ubuntu Saucy

Which version are you using?  (run 'go version')

go version go1.1.2 linux/amd64

(also tip)

Please provide any additional information below.

It seems to be to do with the order of arguments to the link command.  I'll dig more
soon.

[mwhudson]

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.

[robpike]

Comment 2:

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

Status changed to Accepted.

[rsc]

Comment 3:

Labels changed: added go1.3maybe.

[dsymonds]

Comment 4:

Labels changed: added toolbug.

[rsc]

Comment 5:

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

[rsc]

Comment 6:

Labels changed: added repo-gccgo.

[mwhudson]

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...

[ianlancetaylor]

Comment 8:

Yes, this is Repo-Main.

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

[davecheney]

Comment 9:

This issue was closed by revision 9f8f0a1.

Status changed to Fixed.