pathrs-lite supports transparently switching to libpathrs.so as the
backend with the "libpathrs" build tag. In order to make this work
properly with our CI and release build scripts, we we need to have a
similar setup as with we do with libseccomp.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
The intention of commit 531e29e192 ("script/lib.sh: set GOARM=5 for
armel, GOARM=6 for armhf") was to properly support older ARM platforms
with our release builds.
However, we have never been able to support ARMv6 for our builds because
we use the Debian compiler to build the libseccomp we statically compile
into our binaries and (as per the now-deleted comment itself) Debian
treats armhf as being ARMv7 so the final binaries we produced were
always only ever compatible with ARMv7+.
This was a bit of an oddity before but when building libpathrs for
releases we will need to use Rust which makes the target more explicit
(and while it does support armhf, we are using the Debian-packaged Rust
cross-compiler and thus are in the same dilemma with what Debian
considers "armhf" to be).
All-in-all, it's better to just bite the bullet and just follow Debian
here properly.
Fixes: 531e29e192 ("script/lib.sh: set GOARM=5 for armel, GOARM=6 for armhf")
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
"armhf" means ARMv7 for Debian, ARMv6 for Raspbian.
ARMv6 is chosen here for compatibility.
https://wiki.debian.org/RaspberryPi
> Raspberry Pi OS builds a single image for all of the Raspberry families,
> so you will get an armhf 32-bit, hard floating-point system, but built
> for the ARMv6 ISA (with VFP2), unlike Debian's ARMv7 ISA (with VFP3)
> port.
Prior to this commit, the script was setting GOARM=6 for armel,
GOARM=7 for armhf.
Fix issue 4033
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
We need these to match the Makefile detection of the right gcc for
runc-dmz, as well as making sure that everything builds properly for our
cross-i386 tests. While we're at it, add x86 to the list of build
targets for release builds (presumably nobody will use it, but since we
do test builds of this anyway it probably won't hurt).
In addition, clean up the handling of the native architecture build by
treating it the same as any other build (ensuring that building runc
from a different platform will work the same way regardless of the
native architecture). In practice, the build works the same way as
before.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
This implements cross-build for "make release", moving the build into a
container. This way we can support arm, arm64, ppc, and whatnot.
* script/seccomp.sh: separate out of script/release.sh, amend to support
cross-compile and save needed environment variables to a file.
* Dockerfile: add installing libseccomp from source, as this is needed
for release builds.
* script/release.sh: amend to support more architectures in addition to
the native build. Additional arches can be added by specifying
"-a <arch>" argument (can be specified multiple times), or
"make RELEASE_ARGS="-a arm64" release" if called via make.
All supported architectures can be enabled via "make releaseall".
* Makefile: move "release" target to "localrelease", add "release" and
"releaseall" targets to build via the Dockerfile. This is done because
most distros (including Fedora and openSUSE) lack cross-glibc, which is
needed to cross-compile libseccomp.
* Makefile: remove 'cross' and 'localcross' targets, as this is now done
by the release script.
* .github/workflows/validate.yum: amend the release CI job to cross-build
for supported architectures, remove cross job.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Aleksa Sarai