runtime/race: Race Detector and GCC 10.3.0 Problem

[henryas]

Hi,

I have been having problems building Go projects with race detector switched on. I suspect it has something to do with GCC 10.3.0. I wonder whether everyone else is having the same problem.

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

go1.16.5 windows/amd64

Does this issue reproduce with the latest release?

Yes

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

set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Henry\AppData\Local\go-build
set GOENV=C:\Users\Henry\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\Henry\Documents\Projects\Go\pkg\mod
set GONOPROXY=github.com/henryas
set GONOSUMDB=github.com/henryas
set GOOS=windows
set GOPATH=C:\Users\Henry\Documents\Projects\Go
set GOPRIVATE=github.com/henryas
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\Users\Henry\Programs\go\goroot
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\Users\Henry\Programs\go\goroot\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.16.5
set GCCGO=gccgo
set AR=ar
set CC=C:\TDM-GCC-64\bin\gcc.exe
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\Henry\Documents\Projects\Go Projects\toy\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\Henry\AppData\Local\Temp\go-build2138289623=/tmp/go-build -gno-record-gcc-switches

What did you do?

Build any project (even a simple Hello World project) with race detector switched on.

What did you expect to see?

It should build successfully.

What did you see instead?

C:/TDM-GCC-64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(/2203): duplicate symbol reference: _unlock_file in both
libgcc(.text) and libgcc(.data)
libgcc(.text): relocation target ___chkstk_ms not defined
libgcc(.text): relocation target atexit not defined

Is this a bug on Go's end or gcc's end?

[ALTree]

A similar error was reported in #43195 (comment). It seems it may be caused by certain gcc toolchains, on Windows.

[ALTree]

Closing as a dup of #43195.

[ajr360]

Sorry but I don't believe this should have been closed. First, it is not the same a #43195 - the problem is mentioned in #43195 but not resolved there either. Also I do not believe it is related to a particular toolchain as I have reproduced it using all suggested toolchains using various gcc versions from 5.1 to 12.1.

My own experience is that I had been building using the -race option fine for years (using tdm64-gcc-5.1.0-2). I recently installed other software (Ruby) which triggered the problem. I have tried all the suggested toolchains here and in all the linked issues and in other places and continue to get the "duplicate symbol reference" errors (though with different symbols) when using the -race option.

[ianlancetaylor]

Please try using the go build option -ldflags=-linkmode=external. Does that cause the same thing to happen?

[kostix]

Please try using the go build option -ldflags=-linkmode=external. Does that cause the same thing to happen?

I was experiencing the same problem, but this time—while cross-compiling on linux/amd64 with Go 1.17.13 to windows/amd64 with -race and using gcc-mingw-w64-x86-64-win32 10.2.1-6+24.2 (Debian 11 "Buster").
I first came across this post by @ajr360, then saw a hint on external linking in #43195, and finally arrived here.

So, external linking helps; thanks, Ian.

In my particular case, using

CGO_ENABLED=1 CC=/usr/bin/x86_64-w64-mingw32-gcc CGO_LDFLAGS='-static-libgcc -static' GOOS=windows go build -ldflags='-linkmode external' -race

produces a fully-working executable without any errors (CGO_LDFLAGS are irrelevant to this particular problem: they are here to make the generated binary not dependent on libgcc.dll et al).

---

On a side note, I admit it's a bit interesting that cross-compiling using the same setup to windows/i386 (w/o the -race flag which only works on 64-bit platforms) using the same MinGW cross-compiler but for i686 platform (that is, with CC=/usr/bin/i686-w64-mingw32-gcc) does not require -ldflags='-linkmode=external' for compilation to complete successfully (the probject does use cgo). The difference might be in that this cross-compiling I'm talking about was to produce a DLL. May be the difference is between producing an executable image and a DLL.