Description
What version of Go are you using (go version
)?
$ go version go version go1.21.1 windows/amd64
Does this issue reproduce with the latest release?
1.21.1 is the latest version available in MSYS2. I tried the official Windows binary release of 1.21.2, but it doesn't support cgo so it fails before the linking step. For what it's worth I don't see anything that looks relevant in the commits between 1.21.1 and 1.21.2.
What operating system and processor architecture are you using (go env
)?
Windows 11, amd64
go from the MSYS2 package mingw-w64-ucrt-x86_64-go
GNU Binutils 2.41 from the MSYS2 package mingw-w64-ucrt-x86_64-binutils
go env
Output
$ go env set GO111MODULE= set GOARCH=amd64 set GOBIN= set GOCACHE=C:\Users\maia\AppData\Local\go-build set GOENV=C:\Users\maia\AppData\Roaming\go\env set GOEXE=.exe set GOEXPERIMENT= set GOFLAGS= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOINSECURE= set GOMODCACHE=C:\Users\maia\go\pkg\mod set GONOPROXY= set GONOSUMDB= set GOOS=windows set GOPATH=C:\Users\maia\go set GOPRIVATE= set GOPROXY=https://proxy.golang.org,direct set GOROOT=C:/msys64/ucrt64/lib/go set GOSUMDB=sum.golang.org set GOTMPDIR= set GOTOOLCHAIN=auto set GOTOOLDIR=C:\msys64\ucrt64\lib\go\pkg\tool\windows_amd64 set GOVCS= set GOVERSION=go1.21.1 set GCCGO=gccgo set GOAMD64=v1 set AR=ar set CC=gcc set CXX=g++ set CGO_ENABLED=1 set GOMOD=C:\Users\maia\code\snafu\go-hotplug\go.mod set GOWORK= set CGO_CFLAGS=-O2 -g set CGO_CPPFLAGS= set CGO_CXXFLAGS=-O2 -g set CGO_FFLAGS=-O2 -g set CGO_LDFLAGS=-O2 -g set PKG_CONFIG=pkg-config set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\msys64\tmp\go-build1188127562=/tmp/go-build -gno-record-gcc-switches
What did you do?
Attempt to build the example program in elemecca/go-hotplug
go build -x ./examples/announcehid
What did you expect to see?
It should successfully produce an executable, or promptly fail if I did something wrong in my code. Either way it should consume a reasonable amount of memory while doing so.
What did you see instead?
During the cmd/link
step at the end of the build, ld.exe
allocates memory continuously and never finishes.
On my machine, which has 64 GB of RAM, it allocates about 2 GB/second until it hits somewhere around 60 GB, then slows down when the system starts swapping furiously. For science I let it keep running once; Windows bluescreened when it had allocated about 215 GB.
Since the issue is in ld.exe
it's possible this is an upstream bug in GNU Binutils, but I don't know enough about how cmd/link
works to determine that or to give them enough information for a bug report.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status