-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Backport riscv64 support into 1.1.x #3905
Backport riscv64 support into 1.1.x #3905
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use git cherry-pick -x
Done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
CI failure is being fixed in #3909. Once that one is merged, we need to rebase this PR. |
Please rebase |
We do not use all the files from scripts, only seccomp.sh and lib.sh. This prevents unneeded rebuild of the image if e.g. scripts/release_build.sh has changed. Signed-off-by: Kir Kolyshkin <[email protected]> (cherry picked from commit d542ad6)
Dockerfile used to install libseccomp-dev packages for different architectures. This is no longer true since commit f30244e, which changed to cross-compiling libseccomp (so we can get a static library to link against). Thus, adding extra architectures is no longer needed. Signed-off-by: Kir Kolyshkin <[email protected]> (cherry picked from commit 476aa18)
All we need is gcc, libc-dev, and binutils. In addition to that, crossbuild-essential installs g++, libstdc++-dev, and a bunch of perl packages and libraries which we do not need. This should speed up image building, as well as make it smaller. Signed-off-by: Kir Kolyshkin <[email protected]> (cherry picked from commit f0f1b5f)
LDFLAGS_COMMON are used from two places, so it makes sense to dedup. LDFLAGS_STATIC is a preparation for the next commit. Signed-off-by: Kir Kolyshkin <[email protected]> (cherry picked from commit f2f6e59)
1. Set to empty value by default. 2. Assume Linux (remove GOOS check, since we do not support other OSes). 3. Instead of using a "not-supported" list, use a "supported" list (as Go release notes usually say which platforms are supported). As of today, -buildmode=pie is supported for: * linux/386, linux/amd64, linux/arm, linux/arm64, and linux/ppc64le (since Go 1.6, see https://tip.golang.org/doc/go1.6#compiler) * linux/s390x (since Go 1.7, which adds the initial port) * linux/riscv64 (since Go 1.16, see https://tip.golang.org/doc/go1.16#riscv) NOTE this does not mean we support these architectures; it is merely a way to see if -buildmode=pie can be used. Signed-off-by: Kir Kolyshkin <[email protected]> (cherry picked from commit ab5c60d)
Signed-off-by: Kir Kolyshkin <[email protected]> (cherry picked from commit 21e32d4)
It doesn't matter whether static or dynamic linking is used, runc always needs libcontainer/nsenter, which is written in C and thus requires cgo. Same is true for libcontainer/integration. In addition, contrib/pkg/seccompagent also needs cgo (if seccomp build tag is set), as it need to be linked against libseccomp C library. By default, cgo is disabled when cross-compiling, meaning that CGO_ENABLED=1 has to be set explicitly in such cases. In all other cases (e.g. other contrib binaries) we do not need cgo. Remove CGO_ENABLED=1 from GO_BUILD_STATIC (as it does not have anything to do with static linking), and add it to all targets that require it. Signed-off-by: Kir Kolyshkin <[email protected]> (cherry picked from commit dafcacb)
Co-authored-by: Kir Kolyshkin <[email protected]> Signed-off-by: Akihiro Suda <[email protected]> Signed-off-by: Kir Kolyshkin <[email protected]> (cherry picked from commit 1d7b297)
Signed-off-by: Kir Kolyshkin <[email protected]> (cherry picked from commit a14cc40)
Head branch was pushed to by a user without write access
Done. |
This is necessary for running on RISC-V using K3s.
Many projects - including K3s - depend on runc 1.1.x, so waiting for a 2.0.x release and then porting to any changes introduced may probably be a much larger effort. This includes all changes done in #3446, which are really minimal but necessary to support the new architecture.
With this patch I have successfully compiled and run K3s on a RISC-V QEMU VM and have verified that I can create Pods.