Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
cmd/go: go test -compiler gccgo produces duplicate symbol errors #7627
Comments
Here is what I *think* is happening, Under -compiler gc, the _test.go files are combined with the normal files for the package under test and placed into a .a file in $WORK, then everything is linked together /home/dfc/go/pkg/tool/linux_amd64/6l -o $WORK/issue/a/_test/a.test -L $WORK/issue/a/_test -L $WORK -L /home/dfc/pkg/linux_amd64 -w -extld=clang $WORK/issue/a/_test/main.a $WORK/issue/a/_test/a.test you can see that -L $WORK/issue/a/_test comes before -L $WORK so all the symbols for issue/a will be taken from the temporary test .a file in $WORK/issue/a/_test. But, under -compiler gccgo we see gccgo -o $WORK/issue/a/_test/a.test $WORK/issue/a/_test/main.o -Wl,-( -m64 $WORK/issue/a/_test/issue/liba_test.a $WORK/issue/libb.a $WORK/issue/liba.a $WORK/issue/a/_test/issue/liba.a -Wl,-) specifically $WORK/issue/liba.a appears before $WORK/issue/a/_test/issue/liba.a so the linker lodas issue/liba.a but can't find all the symbols it needs, so falls through to _test/issue/liba.a which has the additional test related symbols, but also has symbols that were previously discovered in the previous liba.a. This is all just speculation, I don't know how /usr/bin/ld does it's symbol resolution, but it would make sense to defer opening a library until it's know that none of the previous libraries had all the symbols you needed. The solution would appear to be, make sure that _test/issue/liba.a comes first in the linking order as it does with -compiler gc |
https://golang.org/cl/80300043/ Owner changed to @davecheney. Status changed to Started. |
|
This issue was closed by revision 3ce1677. Status changed to Fixed. |
davecheney
added
fixed
labels
Mar 26, 2014
rsc
added this to the Go1.3 milestone
Apr 14, 2015
rsc
removed
the
release-go1.3
label
Apr 14, 2015
gopherbot
locked and limited conversation to collaborators
Jun 25, 2016
gopherbot
added
the
FrozenDueToAge
label
Jun 25, 2016
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
davecheney commentedMar 25, 2014
What steps will reproduce the problem? See attached zip file for reproduction What is the expected output? What do you see instead? This sample passes with -compiler gc % go test -compiler gc -v issue/... === RUN TestData --- PASS: TestData (0.00 seconds) a_test.go:6: 0 false === RUN TestXData --- PASS: TestXData (0.00 seconds) x_test.go:7: foo &{0 false } PASS ok issue/a 0.005s ? issue/b [no test files] But blows up due to duplicate symbols during linking of a/a.test ucky(~/src) % go test -compiler gccgo -v issue/... # testmain /tmp/go-build896181789/issue/a/_test/issue/liba.a(a.o):(.rodata.__go_tdn_issue_a..issue_a.t+0x0): multiple definition of `__go_tdn_issue_a..issue_a.t' /tmp/go-build896181789/issue/liba.a(a.o):(.rodata.__go_tdn_issue_a..issue_a.t+0x0): first defined here /tmp/go-build896181789/issue/a/_test/issue/liba.a(a.o): In function `issue_a.TestData': /home/dfc/src/issue/a/a_test.go:5: multiple definition of `issue_a.Data' /tmp/go-build896181789/issue/liba.a(a.o):(.bss+0x0): first defined here /tmp/go-build896181789/issue/a/_test/issue/liba.a(a.o): In function `issue_a..import': /home/dfc/src/issue/a/a.go:1: multiple definition of `issue_a..import' /tmp/go-build896181789/issue/liba.a(a.o):/home/dfc/src/issue/a/a.go:1: first defined here collect2: error: ld returned 1 exit status FAIL issue/a [build failed] ? issue/b [no test files] Please use labels and text to provide additional information. Looking at the -x output for go test issue/a gccgo -o $WORK/issue/a/_test/a.test $WORK/issue/a/_test/main.o -Wl,-( -m64 $WORK/issue/a/_test/issue/liba_test.a $WORK/issue/libb.a $WORK/issue/liba.a $WORK/issue/a/_test/issue/liba.a -Wl,-) liba.a is present twice, once in it's normal form, and once in it's extended (due to the export_test.go) form. I am guessing that the first liba.a leaks in due to the transitive import via issue/b.Attachments: