enricobuehlerandClaude Opus 5
000f8b85b0
Adds punktfunk-rust-ci-arm64cross (the rust-ci toolchain + an Ubuntu ports
arm64 multiarch sysroot) and a deb.yml job that cross-builds the client
package on the ordinary amd64 runner — no arm64 runner in the fleet and
none needed. Client only: the Linux host encodes with NVENC/QSV/AMF, all
x86. The apt registry keys pool entries by the .deb's own arch, so an arm64
box picks the package up with no client-side configuration.
Three things this had to get right, each of which cost a failed build:
* rustup target add must run against the toolchain rust-toolchain.toml
PINS, not the image's default `stable` — otherwise the pinned toolchain
has no aarch64 std and the build dies ~230 crates in on "can't find
crate for core". Copying the pin file in also pre-downloads the
toolchain every CI job currently re-fetches on first use.
* ffmpeg-sys-next compiles a probe it intends to RUN, so it forces
.target(HOST) while still passing the TARGET's include paths; the arm64
dir then shadows the host's own libc headers and the x86 compiler dies
in bits/math-vector.h on NEON/SVE types. Prepending the host dir does
NOT help — GCC drops a -I that duplicates a system directory, keeping
its original later position — so ci/pf-host-cc strips target include
dirs from host compiles instead.
* the job hard-fails on a non-AArch64 session binary, rather than
shipping an amd64 payload under an arm64 package name.
skia needs no special handling: the aarch64-linux-gnu textlayout+vulkan
prebuilt resolves, so arm64 ships the FULL client, OSD included — unlike
Windows ARM64, which still builds --no-default-features.
The cross image builds in its own docker.yml job (needs: build-push) since
it is FROM punktfunk-rust-ci:latest and must not race the entry that
publishes that base. rpm/Arch/Flatpak stay x86_64 for now — their builders
have no arm64 sysroot, which is its own piece of work.
Plan: punktfunk-planning design/embedded-arm64-client.md
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
46 lines
1.7 KiB
Bash
46 lines
1.7 KiB
Bash
#!/bin/bash
|
|
# Host-side C compiler wrapper for the aarch64 cross image (ci/rust-ci-arm64cross.Dockerfile).
|
|
#
|
|
# Why this exists: ffmpeg-sys-next's build script compiles a probe it intends to RUN — it
|
|
# executes the binary to read the libav* version macros — so it forces `.target(HOST)` with
|
|
# the comment "don't cross-compile this", but still hands that host compile the TARGET's
|
|
# pkg-config include paths. `-I/usr/include/aarch64-linux-gnu` then shadows the host's own
|
|
# multiarch libc headers and the x86 compiler dies inside bits/math-vector.h on NEON/SVE
|
|
# types it has never heard of.
|
|
#
|
|
# Prepending the host's multiarch dir does NOT fix it: GCC drops a `-I` that duplicates a
|
|
# directory already on its system include path (keeping it in the original, later position),
|
|
# so the arm64 dir stays in front. The reliable fix is to remove the target include dirs from
|
|
# the host compile entirely — the probe only wants FFmpeg's version macros, and the amd64
|
|
# libav*-dev headers are installed and on the default search path, at the same version (both
|
|
# come from this Ubuntu release).
|
|
#
|
|
# Scope: only ever invoked as CC for the HOST triple (CC_x86_64_unknown_linux_gnu). Target
|
|
# compiles go to aarch64-linux-gnu-gcc and never pass through here.
|
|
set -euo pipefail
|
|
|
|
declare -a out=()
|
|
while (($#)); do
|
|
case "$1" in
|
|
# `-I dir` as two arguments — the form cc's Command building and ffmpeg-sys both emit.
|
|
-I)
|
|
if [[ ${2-} == *aarch64-linux-gnu* ]]; then
|
|
shift 2
|
|
continue
|
|
fi
|
|
out+=("$1" "${2-}")
|
|
shift 2
|
|
;;
|
|
# `-Idir` glued into one argument.
|
|
-I*aarch64-linux-gnu*)
|
|
shift
|
|
;;
|
|
*)
|
|
out+=("$1")
|
|
shift
|
|
;;
|
|
esac
|
|
done
|
|
|
|
exec /usr/bin/cc "${out[@]}"
|