golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
121.3k stars 17.38k forks source link

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

Closed andig closed 1 year ago

andig commented 1 year ago

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: https://github.com/evcc-io/evcc/issues/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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

see #57328

pplmx commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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?
Pim-Infuzed commented 1 year ago

Same issue here, but setting CGO_ENABLED=0 does not solve my problem (still getting the same error). Also I tried go version -m on my build environment and it was not supported (just downgraded the use a 1.19 image due to this CGO problem. I need build once, run everywhere (any linux). If CGO_ENABLED=0 is not working, how can I stay with the latest go and not suffer from this feature that was introduced for a very specific audience?

giautm commented 1 year ago

if you build your code in docker for arm, with arm64v8/golang:1.20 image. There is a change that upgrade the base OS from bullseye to bookworm. So the version of glibc was changed.

Pim-Infuzed commented 1 year ago

@giautm thnx, however I do not want my app to be linux distribution specific. This would mean I have to build for each distribution and each of their releases I need to support.

ianlancetaylor commented 1 year ago

@Pim-Infuzed This issue is closed. If you are having trouble I suggest that you ask on a forum, with full details about what you are doing. See https://go.dev/wiki/Questions. Thanks.

nihavend commented 1 year ago

here is my case may help others Stackoverflow

lunicon commented 6 months ago

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

Tectract commented 3 months ago

How to fix this error? I need to compile a chain and now ignite is suddenly not working on my system.

solved by forcing the build to CGO_ENABLED=0

Ok I did:

export CGO_ENABLED=0
curl https://get.ignite.com/cli! | bash

now, still:

ignite version
ignite: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ignite)

what? How do I fix it???