Giters

google / gvisor

Application Kernel for Containers

Home Page:https://gvisor.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Build failed on darwin amd64

Dreamacro opened this issue · comments

commented

Description

build output

❯ make darwin-amd64
GOARCH=amd64 GOOS=darwin CGO_ENABLED=0 go build ...
# gvisor.dev/gvisor/pkg/sighandling
../../../go/pkg/mod/gvisor.dev/gvisor@v0.0.0-20211108085032-a42ea3ee63e8/pkg/sighandling/sighandling_unsafe.go:31:33: undefined: unix.SYS_RT_SIGACTION
../../../go/pkg/mod/gvisor.dev/gvisor@v0.0.0-20211108085032-a42ea3ee63e8/pkg/sighandling/sighandling_unsafe.go:35:33: undefined: unix.SYS_RT_SIGACTION
../../../go/pkg/mod/gvisor.dev/gvisor@v0.0.0-20211108085032-a42ea3ee63e8/pkg/sighandling/sighandling_unsafe.go:55:33: undefined: unix.SYS_RT_SIGACTION
../../../go/pkg/mod/gvisor.dev/gvisor@v0.0.0-20211108085032-a42ea3ee63e8/pkg/sighandling/sighandling_unsafe.go:68:33: undefined: unix.SYS_RT_SIGACTION

after testing, broken happen after 23a115d. I'm using gVisor for a userspace tcpip stack and it works fine for some cases (e.g. wireguard) on darwin. hope that this build broken can be fixed

Steps to reproduce

No response

runsc version

No response

docker version (if using docker)

No response

uname

No response

kubectl (if using Kubernetes)

No response

repo state (if built from source)

No response

runsc debug logs (if available)

No response

commented

I just came to file the same. This also broke us (@tailscale). Or rather, it prevents us from updating to newer versions of gVisor.

We run gVisor's netstack on macOS, Windows, FreeBSD, OpenBSD, etc.

Would it be possible to get some CI coverage inside Google's build system (at least testing that it builds, even if you can't run it) to prevent such regressions in the future?

Or is this intentional, that Linux is now required?

commented

/cc @zkoopmans (in case you're not subscribed to the firehose)

commented

This is not intentional. As noted, I think we need coverage to prevent accidental breaks.

There are smoke tests on the go branch that can probably be easily extended to other GOOS/GOARCH targets:

gvisor/.buildkite/pipeline.yaml

Line 38 in 84b38f4

- go build ./...

I’m not sure we’ll be able to build all packages, however. Is there a list of entry points that folks are generally relying on? E.g. is the transitive closure of the netstack_deps_test good?

gvisor/pkg/tcpip/BUILD

Line 43 in 84b38f4

deps_test(

commented

This is not intentional.

Phew :)

Is there a list of entry points that folks are generally relying on?

I can't speak for everybody, but I suspect our usage is pretty typical of other networking-only gVisor users. Our direct imports are:

                "inet.af/netstack/tcpip",
                "inet.af/netstack/tcpip/adapters/gonet",
                "inet.af/netstack/tcpip/buffer",
                "inet.af/netstack/tcpip/header",
                "inet.af/netstack/tcpip/link/channel",
                "inet.af/netstack/tcpip/network/ipv4",
                "inet.af/netstack/tcpip/network/ipv6",
                "inet.af/netstack/tcpip/stack",
                "inet.af/netstack/tcpip/transport/icmp",
                "inet.af/netstack/tcpip/transport/tcp",
                "inet.af/netstack/tcpip/transport/udp",
                "inet.af/netstack/waiter",

(Ignore the inet.af/netstack rewritten path hack to work around go.mod issues; I think we can remove that hack now that we depend on Go 1.17 and its lazy loading: https://golang.org/doc/go1.17#go-command)

And the expanded deps:

                "inet.af/netstack/atomicbitops",
                "inet.af/netstack/buffer",
                "inet.af/netstack/gohacks",
                "inet.af/netstack/linewriter",
                "inet.af/netstack/log",
                "inet.af/netstack/rand",
                "inet.af/netstack/sleep",
                "inet.af/netstack/state",
                "inet.af/netstack/state/wire",
                "inet.af/netstack/sync",
                "inet.af/netstack/tcpip",
                "inet.af/netstack/tcpip/adapters/gonet",
                "inet.af/netstack/tcpip/buffer",
                "inet.af/netstack/tcpip/hash/jenkins",
                "inet.af/netstack/tcpip/header",
                "inet.af/netstack/tcpip/header/parse",
                "inet.af/netstack/tcpip/link/channel",
                "inet.af/netstack/tcpip/network/hash",
                "inet.af/netstack/tcpip/network/internal/fragmentation",
                "inet.af/netstack/tcpip/network/internal/ip",
                "inet.af/netstack/tcpip/network/ipv4",
                "inet.af/netstack/tcpip/network/ipv6",
                "inet.af/netstack/tcpip/ports",
                "inet.af/netstack/tcpip/seqnum",
                "inet.af/netstack/tcpip/stack",
                "inet.af/netstack/tcpip/transport/icmp",
                "inet.af/netstack/tcpip/transport/packet",
                "inet.af/netstack/tcpip/transport/raw",
                "inet.af/netstack/tcpip/transport/tcp",
                "inet.af/netstack/tcpip/transport/tcpconntrack",
                "inet.af/netstack/tcpip/transport/udp",
                "inet.af/netstack/waiter",
commented

I have try inet.af/netstack, it's an excellent subset for people who only use tcpip stack. It saves my go.sum 🤣. But it synced the broken code, can you roll back to the last compilable commit first?

last go branch compilable commit: 2de3450

commented

Re-opening until someone confirms that netstack is building on Mac again.

commented

Haven't tried yet, but looks like that change would leave Windows and FreeBSD and OpenBSD still broken?

commented

Closing now that we build on several OSes and architectures (e.g. https://buildkite.com/gvisor/pipeline/builds/10194). If people want builds on other OSes, architectures, or of other packages, open a bug to discuss.