FS#57921 - [go] Unable to build docker/containerd-shim

Attached to Project: Community Packages
Opened by Sébastien Luttringer (seblu) - Friday, 23 March 2018, 01:54 GMT
Last edited by Morten Linderud (Foxboron) - Sunday, 13 September 2020, 13:33 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Morten Linderud (Foxboron)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Hello,

I'm no more able to compile containerd-shim in docker package with go-pie.
The standalone containerd package is also affected.
Binary versions aged from few months in repository looks good, so something happen in go-pie recently, I don't know what.
Switch to go as deps make error goes away.

The makefile line which fail is:
CGO_ENABLED=0 go build -v -o bin/containerd-shim -ldflags '-s -w -X github.com/containerd/containerd/version.Version=v1.0.2 -X github.com/containerd/containerd/version.Revision=cfd04396dc68220d1cecbe686a6cc3aa5ce3667c -X github.com/containerd/containerd/version.Package=github.com/containerd/containerd -extldflags "-static"' ./cmd/containerd-shim
# github.com/containerd/containerd/cmd/containerd-shim
loadinternal: cannot find runtime/cgo

The fastest way to reproduce is to rebuild containerd package with go-pie.
This task depends upon

Closed by  Morten Linderud (Foxboron)
Sunday, 13 September 2020, 13:33 GMT
Reason for closing:  Won't implement
Additional comments about closing:  go-pie has been dropped and containerd doesn't use PIE anymore.
Comment by Eli Schwartz (eschwartz) - Friday, 23 March 2018, 02:11 GMT
Same problem with gopass, or at least you could compile a binary but it always segfaults.

The "solution" (which seems reasonable IMHO) is to strip out the -static and allow go to at least dynamically link libc.
Comment by Maciek Borzecki (bboozzoo) - Tuesday, 17 April 2018, 18:33 GMT
FWIW this looks like a problem with Go toolchain. Consider a minimal sample like this:

```
package main

import "fmt"

func main() {
fmt.Println("hello")
}
```

When built using either `go` package or upstream go1.10.1 and CGO_ENABLED=0, the resulting binary is not statically linked:

```
$ CGO_ENABLED=0 go build -buildmode=pie main.go
# command-line-arguments
loadinternal: cannot find runtime/cgo
$ ldd main
linux-vdso.so.1 (0x00007ffc57f3d000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f659f253000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f659f9c3000)
```

Version `go version devel +58b18cfda5 Tue Apr 17 14:39:08 2018 +0000 linux/amd64` behaves the same. GOCACHE=off does not seem to have any effect.
Comment by Maciek Borzecki (bboozzoo) - Wednesday, 18 April 2018, 09:37 GMT
I've tested a couple Go versions going back to 1.7. Disabling CGO and `-buildmode=pie` does not appear to work in the previous versions. A reasonable workaround is to leave cgo enabled, but pass -static to ld., eg. `go build -buildmode=pie -ldflags "-extldflags '-static'"`.
Comment by Mateusz Gozdek (invidian) - Wednesday, 22 May 2019, 09:50 GMT
I think there is a workaround for that. You can either try passing explicit `-buildmode=exe` or perhaps `go-pie` should adapt the same patch as Alpine did, where they use `musl` for linking, which seems to work fine then. See https://git.alpinelinux.org/aports/tree/community/go/set-external-linker.patch
Comment by Bartłomiej Piotrowski (Barthalion) - Wednesday, 22 May 2019, 11:55 GMT
They patch the default linker because they don't use glibc, not because it solves build failures for them. In fact, many packages are just not available in Alpine due to the fact they ship only PIE-enforced compiler.

Loading...