arm64: master branch build broken (445fa6f40c89)

[andig]

Description

After upgrading to master due to #8149, builds is broken on MacOS arm64:

go get -u gvisor.dev/gvisor@master
go: downloading gvisor.dev/gvisor v0.0.0-20221129015309-445fa6f40c89
go: upgraded gvisor.dev/gvisor v0.0.0-20220817001344-846276b3dbc5 => v0.0.0-20221129015309-445fa6f40c89

Build:

Starting: /Users/andig/go/bin/dlv dap --check-go-version=false --listen=127.0.0.1:53097 --log-dest=3 from /Users/andig/htdocs/evcc
DAP server listening at: 127.0.0.1:53097
Build Error: go build -o /Users/andig/htdocs/evcc/__debug_bin -gcflags all=-N -l ./main.go
# gvisor.dev/gvisor/pkg/bits
../../go/pkg/mod/gvisor.dev/[email protected]/pkg/bits/uint64_arch.go:35:9: undefined: MaskOf64
# gvisor.dev/gvisor/pkg/waiter
../../go/pkg/mod/gvisor.dev/[email protected]/pkg/waiter/waiter.go:139:2: undefined: waiterEntry
../../go/pkg/mod/gvisor.dev/[email protected]/pkg/waiter/waiter.go:210:7: undefined: waiterList (exit status 2)

Steps to reproduce

Run build

runsc version

No response

docker version (if using docker)

No response

uname

Darwin SkyNetM1.fritz.box 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct 9 20:14:30 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8103 arm64

kubectl (if using Kubernetes)

No response

repo state (if built from source)

No response

runsc debug logs (if available)

No response

[andig]

The bits error is confusing since the last change to the package at https://github.com/google/gvisor/tree/master/pkg/bits has been in 2021. I'm wondering if gvisor is even supported on arm64 at all?

[amscanne]

The master branch has never been buildable directly with Go get, because we use bazel. The synthetic Go branch is maintained as a convenience for this: https://github.com/google/gvisor#using-go-get

[dhaavi]

I just had quite a fight with this.
I am using gVisor as a library and it would and would not build, because of the exact error that OP had.

I tried all variants of go get-ting gvisor with @go and @release-..., but nothing would work.

I finally resolved it by forcing the version via a replace. This is now in my go.mod:

replace gvisor.dev/gvisor => gvisor.dev/gvisor go

The only downside is, that go does not conform to the version format. So, now I always have a red mark on that line.
Would it be possible to publish the go.mod version with a version-format-compatible tag? Eg. v0.0.0-gomod?

[kevinGC]

Might that cause problems, as v0.0.0-gomod would always be HEAD and HEAD changes with every commit?

Could you do something like:

require gvisor.dev/gvisor go

When go mod tidy is run, it'll replace this line with a pseudo-version that I would expect to be considered valid by your editor:

require gvisor.dev/gvisor v0.0.0-20240117011310-b5318a0dd5db
``

[dhaavi]

Thanks for the idea! It seems to work so far.

go mod tidy transformed it into:
require gvisor.dev/gvisor v0.0.0-20240118213851-4eebcff36ffd

I am not sure why this worked now. I did not try to get get that specific version, as it did not exist back then. But I think I tried the same with go get, which did not work.

Okay, so I now did a couple go get with different versions and it broke again, then again did require gvisor.dev/gvisor go and go mod tidy and it works again. So this seems to actually fix the problem. But I don't understand why doing it this way works, when just doing a go get with a specific version does not.

Okay, now just doing go get gvisor.dev/gvisor@go also works. This definitely did not work before.

Welp. Anyway, I hope this will help others in case this happens again.

[kevinGC]

My understanding is that v0.0.0-20240118213851-4eebcff36ffd is a pseduo-version, so you can't actually go get it. What the pseudo-version means is it's commit 4eebcff from time 20240118213851, which allows you to pin to that specific commit in go.mod, much like pinning to a specific regular version like v1.2.3.

I'm not sure about go get gvisor.dev/gvisor@go.