/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found

[andig]

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

$ go version
go version go1.20 darwin/arm64

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="arm64"
GOBIN=""
GOCACHE="/Users/andig/Library/Caches/go-build"
GOENV="/Users/andig/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/andig/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/andig/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.20"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/andig/htdocs/evcc/go.mod"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/sv/rs_453y57xj86xsbz3kw1mbc0000gn/T/go-build3562167146=/tmp/go-build -gno-record-gcc-switches -fno-common"
GOROOT/bin/go version: go version go1.20 darwin/arm64
GOROOT/bin/go tool compile -V: compile version go1.20
uname -v: Darwin Kernel Version 22.2.0: Fri Nov 11 02:04:44 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T8103
ProductName:		macOS
ProductVersion:		13.1
BuildVersion:		22C65
lldb --version: lldb-1400.0.38.17
Apple Swift version 5.7.2 (swiftlang-5.7.2.135.5 clang-1400.0.29.51)

What did you do?

After upgrading our build environment and go.mod requirement to Go 1.20, users started to see this error message on Ubuntu: evcc-io/evcc#6263. The application does not use CGO.

What did you expect to see?

No error. Same build was working fine with Go ^1.18.

What did you see instead?

GLIBC version required. This output of go version -m should be similar to what the build produces for arm:

build	-buildmode=exe
build	-compiler=gc
build	-ldflags="-X github.com/evcc-io/evcc/server.Version=0.109.2 -X github.com/evcc-io/evcc/server.Commit=3ec2d1b70 -s -w"
build	-tags=release
build	CGO_ENABLED=0
build	GOARCH=arm
build	GOOS=linux
build	GOARM=6
build	vcs=git
build	vcs.revision=3ec2d1b70abf2a5a827e43755f5e94df59eb1add
build	vcs.time=2022-12-19T13:08:03Z
build	vcs.modified=true

[seankhliao]

What's the output of go version -m on the actual built binary?
There are parts of the stdlib that will use cgo if not explicitly disabled.

[seankhliao]

Looking at the evcc issue, it's your nightly ubuntu builds.
These are linked against glibc.

As we no longer ship precompiled archives for the standard library,
it's up to you to ensure glibc linking (if you use it, eg using net) works.
https://go.dev/doc/go1.20#go-command

root@c737fabce3a0:/# go version -m /usr/bin/evcc
/usr/bin/evcc: go1.20
	path	command-line-arguments
	...
	build	-buildmode=exe
	build	-compiler=gc
	build	-ldflags="-X github.com/evcc-io/evcc/server.Version=0.112.5 -X github.com/evcc-io/evcc/server.Commit=99595b72 -s -w"
	build	-tags=release
	build	CGO_ENABLED=1
	build	CGO_CFLAGS=
	build	CGO_CPPFLAGS=
	build	CGO_CXXFLAGS=
	build	CGO_LDFLAGS=
	build	GOARCH=amd64
	build	GOOS=linux
	build	GOAMD64=v1
root@c737fabce3a0:/# ldd /usr/bin/evcc 
	linux-vdso.so.1 (0x00007fffde69b000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f943b894000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f943bac1000)

Closing as working as intended.

[andig]

I'm surprised to find this:

       build	-buildmode=exe
	build	-compiler=gc
	build	-ldflags="-X github.com/evcc-io/evcc/server.Version=0.112.5-next -s -w"
	build	-tags=release
	build	CGO_ENABLED=1
	build	CGO_CFLAGS=
	build	CGO_CPPFLAGS=
	build	CGO_CXXFLAGS=
	build	CGO_LDFLAGS=
	build	GOARCH=arm64
	build	GOOS=linux

since the goreleaser config nowhere mentions to enable cgo.

As we no longer ship precompiled archives for the standard library, it's up to you to ensure glibc linking (if you use it, eg using net) works. https://go.dev/doc/go1.20#go-command

I have unfortunately no idea what that means. I've re-read the go command section and am still puzzled what pre-compiled archives (for what?) have to do with the compiled binary.

it's up to you to ensure glibc linking (if you use it, eg using net) works.

And no idea what that means. net is used. Happy to head over to golang nuts, but maybe a small pointer could already help.

[andig]

More specifically, when the CGO_ENABLED environment variable is unset, the CC environment variable is unset, and the default C compiler (typically clang or gcc) is not found in the path, CGO_ENABLED defaults to 0. As always, you can override the default by setting CGO_ENABLED explicitly.

I have CGO_ENABLED unset in the build environment. It's confusing that the build would end with CGO_ENABLED=1? Seems this wasn't the case with Go 1.19.

[ianlancetaylor]

CGO_ENABLED=1 is the default and always has been. It's true that in 1.19 if you built the tools with CGO_ENABLED=0, then the tools would in turn default to building programs with CGO_ENABLED=0. I believe that that is no longer true in 1.20.

[andig]

Thank you both.

I've re-run the golang-releaser build with 1.19 and it ends up with CGO_ENABLED=1, too. With 1.19 that doesn't hurt apparently, with 1.20 it does. I'm not a compiler person and totally fail to make the connection from the Go release notes to the problem observed. I do understand that dynamic linking requires the link targets to be available at runtime. What I don't get is what has changed between 1.19 and 1.20 that makes it behave differently with regards to runtime behaviour.

Happy to not get an answer, solved by forcing the build to CGO_ENABLED=0 which I suspected to be the default all the time. I could imagine though that the change in behaviour will confuse other devs, too.

[seankhliao]

see #57328

[pplmx]

hi, there
how to fix it? I need CGO_ENABLED=1(build a shared object from the go project).
I rollback the go from 1.20.1 to 1.19.6, and the go.mod downgrade to 1.18, this issue still occurred.

[andig]

AFAIU, for CGO_ENABLED=1, you'll need to use a glibc version during compile that matches (or is lower) than the one on your target runtime system.

[pplmx]

Host OS is ubuntu 22.04(I build the so here)
Running Container is ubuntu 18.04(Running the program here)
I need

1. build the so file on ubuntu 18.04, and then run it on the container 18.04, right?
2. Or upgrade my container os version?

[lunicon]

Try to use bullseye official docker image like golang:1.21-bullseye
It user glib 2.31