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?

Why does it work with 1.21?

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

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)

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

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.

$ 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

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.

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

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.

see #65887 (comment)

@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.

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