cmd/go: go test -compiler gccgo produces duplicate symbol errors #7627
Labels
Milestone
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. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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:
The text was updated successfully, but these errors were encountered: