cmd/go: -buildmode=pie requires external (cgo) linking, but cgo is not enabled

[andreas-schwab]

Go version

go version go1.22rc1 linux/riscv64

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

GO111MODULE=''
GOARCH='riscv64'
GOBIN=''
GOCACHE='/home/andreas/.cache/go-build'
GOENV='/home/andreas/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='riscv64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/andreas/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/andreas/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/lib64/go/1.22'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/lib64/go/1.22/pkg/tool/linux_riscv64'
GOVCS=''
GOVERSION='go1.22rc1'
GCCGO='gccgo'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
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 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1658771557=/tmp/go-build -gno-record-gcc-switches'

What did you do?

$ CGO_ENABLED=0 go build -buildmode=pie hellogo.go
-buildmode=pie requires external (cgo) linking, but cgo is not enabled

What did you expect to see?

$ CGO_ENABLED=0 /usr/lib64/go/1.21/bin/go build -buildmode=pie hellogo.go
# command-line-arguments
loadinternal: cannot find runtime/cgo

What did you see instead?

$ CGO_ENABLED=0 go build -buildmode=pie hellogo.go
-buildmode=pie requires external (cgo) linking, but cgo is not enabled

[mauri870]

I think that is expected, riscv does not support internal linking with buildmode=pie. Can you point out to the source that says PIE works without cgo on riscv64?

[andreas-schwab]

Why does it work with 1.21?

[mauri870]

Thanks for the heads-up! There was some logic shifted around in CL 472515 and CL 522239 for #31544 that causes -buildmode=pie to explicitly require CGO_ENABLED=1 with riscv64, this was not a requirement in go 1.21 and earlier. I imagine this also affects linux/s390x the same way.

My understanding is that for riscv64, s390x buildmode=pie do require cgo because of the external linking, so the current behavior is correct, while in 1.21 and earlier we were compiling with cgo anyway, regardless of CGO_ENABLED. But I might be wrong here.

cc @bcmills

[bcmills]

linux/riscv64 is not currently marked as supporting internal linking for PIE binaries. If that is incorrect — that is, if the Go linker actually does support internal linking in this configuration — then internal/platform.InternalLinkPIESupported should be updated (along with any affected tests) to reflect that.

Otherwise, the fact that CGO_ENABLED=0 go build -buildmode=pie hellogo.go previously exited without error is a bug, and the new error here is working as intended.

(attn @golang/riscv64)

[andreas-schwab]

https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/velero-plugin-for-aws/standard/riscv64
https://build.opensuse.org/package/live_build_log/home:Andreas_Schwab:riscv:go/velero-plugin-for-aws/standard/riscv64

[mknyszek]

In triage, are we understanding correctly that, given that -buildmode=pie doesn't work with internal linking on linux/riscv64, that this issue is now basically a feature request for this behavior?

Even though the build didn't fail for Go 1.21, did we really support -buildmode=pie with internal linking? It looks to us like in Go 1.21 the toolchain would just silently build a non-PIE binary, which seems undesirable.

[andreas-schwab]

$ readelf -h usr/bin/velero-plugin-for-aws
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Position-Independent Executable file)
Machine: RISC-V
Version: 0x1
Entry point address: 0x3165e0
Start of program headers: 64 (bytes into file)
Start of section headers: 35051632 (bytes into file)
Flags: 0x5, RVC, double-float ABI
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 11
Size of section headers: 64 (bytes)
Number of section headers: 33
Section header string table index: 32

[bcmills]

I wonder if in practice it used the C linker (despite CGO_ENABLED being false) and produced a C-linked binary missing the runtime's usual C support code.

[nmeum]

Hi, Alpine Linux maintainer here 👋 We use -buildmode=pie by default for all Go packages in our repository. Since Go 1.22 we are running into a lot of build failures as there seems to be a lot of software which sets CGO_ENABLED=0 in Makefiles and other go build-wrappers, for example fq. Just checking in here to make sure that this is intended. If so, I believe we have to patch all software which sets CGO_ENABLED=0?

See: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15809

[Xeonacid]

Hi, Alpine Linux maintainer here 👋 We use -buildmode=pie by default for all Go packages in our repository. Since Go 1.22 we are running into a lot of build failures as there seems to be a lot of software which sets CGO_ENABLED=0 in Makefiles and other go build-wrappers, for example fq. Just checking in here to make sure that this is intended. If so, I believe we have to patch all software which sets CGO_ENABLED=0?

We are from Arch Linux RISC-V and having the exact same problem.

[seankhliao]

see #65887 (comment)

[bcmills]

@nmeum, @Xeonacid: correct. If the Go linker requires an external (C) linker for -buildmode=pie on a given platform, then cgo must also be enabled in order to link PIE binaries on that platform.

[gopherbot]

Change https://go.dev/cl/569296 mentions this issue: _content/doc: mention cgo requirements for external linking in release notes for Go 1.21 and 1.22