cmd/go: Duplicate symbols with more than one main package in -coverpkg

[rodrigo-toledo]

What version of Go are you using (go version)?

$ go version
go version go1.13 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/rtoledo/Library/Caches/go-build"
GOENV="/Users/rtoledo/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/rtoledo/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/5f/_qpgtfqn50v9076584zs6p6cns_ysz/T/go-build619092751=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

go test ./... -coverpkg=./...

What did you expect to see?

Tests running OK.

What did you see instead?

2019/09/05 11:57:31 duplicate symbol main.main (types 1 and 1) in main and /Users/rtoledo/Library/Caches/go-build/ee/ee28c25020a2b94486bc9068230305877cfb8f0f08d992d0c5a33faa6bdea84c-d(go.o)

This might be a regression for #32150. Sorry I cannot provide a working example, the bug is kinda esoteric to me and I cannot create a shareable project where this happens.

Edit: How to reproduce
#34114 (comment)

[rodrigo-toledo]

Also, it works without problem in 1.12.9

[jcarm010]

I am seeing this same issue with go 1.13 in darwin

[arteev]

I also see the same problem with go version go1.13 linux/amd64

[ojrac]

We're also seeing this on go1.13 linux/amd64, though I can't get it to reproduce outside our build machine.

Deleting .cache/go-build had no effect, other than to change the error output to this -- I haven't been able to find who sets $WORK, but there are no _pkg_.a or _go_.o files on disk:

2019/09/10 10:00:49 duplicate symbol main.main (types 1 and 1) in main and $WORK/b318/_pkg_.a(_go_.o)

go env Output (from failing machine)

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/usr/share/tomcat8/.cache/go-build"
GOENV="/usr/share/tomcat8/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/usr/share/tomcat8/.jenkins/workspace/code-coverage"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/share/tomcat8/.jenkins/workspace/code-coverage/.build_env/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/share/tomcat8/.jenkins/workspace/code-coverage/.build_env/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -gno-record-gcc-switches"

[maxatome]

Don't know if it can help, but this problem appeared systematically in one repo with vendor/ directory and so built with -mod vendor + code coverage enabled. Converting it to go.mod (still with code coverage enabled) fixed the problem.

[emiguens]

I'm seeing the same problem here (no problem with Go <= 1.12.x).

After the comment from @maxatome I made some tests on our private project.
Running go test ./... -coverprofile=coverage.out -coverpkg=./... -count=1 the results are:

1. Using dep as dependency management, having a vendor folder with dependencies. Tests fail with "duplicate symbol" error.
2. Using go mod as dependency management, without vendor folder. Tests pass successfully.
3. Using go mod with vendor folder (executing go mod vendor). Tests pass successfully.
4. Using go mod with vendor folder. But setting GO111MODULE=off. Tests fail with "duplicate symbol" error.

Didn't try replicating this behavior on an example repo, might try doing so in the following days if time permits.

[emiguens]

I've managed to create a very small repo that reproduces the issue: https://github.com/emiguens/go-cover-fail.

After cloning the repo just run go test ./... -coverprofile=coverage.out -coverpkg=./... -count=1 and you'll see the following output:

$ go test ./... -coverprofile=coverage.out -coverpkg=./... -count=1
?   	github.com/emiguens/go-cover-fail	[no test files]
# github.com/emiguens/go-cover-fail/pkg1.test
2019/09/10 19:27:09 duplicate symbol main.main (types 1 and 1) in main and /Users/emiguens/Library/Caches/go-build/24/24691ab861edac4f0767346c8d02eb886ed269874dacb9e5f27dc53368bb053c-d(_go_.o)
FAIL	github.com/emiguens/go-cover-fail/pkg1 [build failed]
# github.com/emiguens/go-cover-fail/pkg2.test
2019/09/10 19:27:09 duplicate symbol main.main (types 1 and 1) in main and /Users/emiguens/Library/Caches/go-build/24/24691ab861edac4f0767346c8d02eb886ed269874dacb9e5f27dc53368bb053c-d(_go_.o)
FAIL	github.com/emiguens/go-cover-fail/pkg2 [build failed]
FAIL

If I remove the main.go file and re-run the command, it executed correctly.

Another scenarios:

• Removing /vendor and Gopkg.* files, making the tests use dependencies from $GOPATH results in the same error.
• Migrating the dependencies to Go modules, makes the tests pass.
• As my previous comment, using go modules, running go vendor and executing the command with GO111MODULE=offresults in tests failing.

All in all it seems to be something related with using a vendor folder with dependencies.

Hope this helps =D

[FiloSottile]

@gopherbot please open a backport issue for Go 1.13, this looks like a possible regression without a workaround.

/cc @bcmills @jayconrod

[gopherbot]

Backport issue(s) opened: #34223 (for 1.13).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

[emiguens]

I've further reduced the test case, now it fails without having any external dependencies (only using the standard library). Just a main package with a subpackage with one function, so no vendor directory either.

After running go mod init (creates a go.mod file with no dependencies) tests run fine.

Just in case, you can see the commit history in the linked project to see how the test case evolved.

[bcmills]

See previously #30374 and #32150.