Also, it works without problem in 1.12.9

I am seeing this same issue with go 1.13 in darwin

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

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

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.

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.

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

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

/cc @bcmills @jayconrod

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.

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.

See previously #30374 and #32150.

This has the same root cause as #30907, but it affects packages built in GOPATH mode. Previously, I believed this bug only affected build info for modules, so the fix was pretty narrow. I'll send a CL that broadens the fix to cover this case.

Change https://golang.org/cl/195279 mentions this issue: cmd/go: fix link error for -coverpkg in GOPATH mode