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)?
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
set GOMOD=C:\Users\Henry\Documents\Projects\Go Projects\toy\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
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?
The text was updated successfully, but these errors were encountered:
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.
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.