From a1ff6de65274c553a856854e6913008296ae0017 Mon Sep 17 00:00:00 2001 From: Markus Fritsche Date: Wed, 20 May 2026 14:31:40 +0200 Subject: [PATCH] libva-v4l2-request-fourier-debian: pin trixie libva-dev for ABI MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The libva-v4l2-request-fourier .deb shipped with the wrong VA-API symbol export because the CI runner is Arch (libva 2.23 = VA-API 1.23) while the install target is Debian trixie (libva 2.22 = VA-API 1.22). At compile time, 's VA_MAJOR/VA_MINOR macros are baked into the driver's __vaDriverInit__ symbol name. trixie's libva runtime looks up __vaDriverInit_1_22, our driver only exported __vaDriverInit_1_23, so dlsym() returned NULL and libva fell back to its sentinel error "has no function __vaDriverInit_1_0". Result: ffmpeg -hwaccel vaapi fails on startup, vainfo fails the same way, on every Pi 5 / CM5 that installed the package. The driver itself doesn't link libva.so (no NEEDED entry — confirmed via readelf on higgs), so the only thing that matters is the symbol NAME the compiler bakes in. Fix is small: in build-deb.sh, download trixie's libva-dev / libva2 / libva-drm2 .deb from deb.debian.org, extract to a sysroot, rewrite the .pc prefixes, and set PKG_CONFIG_PATH so pkg-config returns trixie headers regardless of what the runner has installed. The link step still resolves -lva against the sysroot's libva.so.2, but the resulting .so has no NEEDED entry for it. Added a hard sanity check at the end of build-deb.sh: fail the build if the produced .so doesn't export __vaDriverInit_1_22. This makes future ABI-skew failures loud at CI time instead of silent install- then-refuse-to-load on the target. Tested on boltzmann (aarch64): sysroot build produces a .so exporting __vaDriverInit_1_22 (verified via nm -D). Source unchanged from c332d34; only the build env differs. pkgver/upstream unchanged. PKGREL bumped 1 -> 2 (rebuild against pinned trixie libva-dev) so apt picks up the new .deb on higgs. This is the LIBVA-2 unblocker — the runtime-libva-bind failure was masking whether the LIBVA-1 per-codec dispatch actually works on higgs. Once -2 lands on packages.reauktion.de, apt upgrade on higgs and the daedalus daemon log + rpi-hevc-dec dispatch can be validated end-to-end. Co-Authored-By: Claude Opus 4.7 --- .../libva-v4l2-request-fourier/build-deb.sh | 54 ++++++++++++++++++- .../debian/changelog | 18 +++++++ 2 files changed, 71 insertions(+), 1 deletion(-) diff --git a/debian/libva-v4l2-request-fourier/build-deb.sh b/debian/libva-v4l2-request-fourier/build-deb.sh index 9d15f1d77..79ae918c9 100755 --- a/debian/libva-v4l2-request-fourier/build-deb.sh +++ b/debian/libva-v4l2-request-fourier/build-deb.sh @@ -16,7 +16,7 @@ set -euo pipefail # on 'p' (rpi-hevc-dec). UPSTREAM_COMMIT=c332d34643be29e88012e30878d2fbeb255b20ab PKGVER=1.0.0+r378+gc332d34 -PKGREL=1 +PKGREL=2 # rebuild against pinned trixie libva-dev (2.22) for __vaDriverInit_1_22 ABI HERE=$(dirname "$(readlink -f "$0")") @@ -27,6 +27,47 @@ work=$(mktemp -d) trap "rm -rf $work" EXIT cd "$work" + +# --------------------------------------------------------------------------- +# Pin libva ABI to Debian trixie's version (libva 2.22.0 -> VA-API 1.22). +# +# Without this, when the CI runner is Arch (libva 2.23.0 currently) the +# driver compiles in __vaDriverInit_1_23 from Arch's — but the +# Debian trixie libva runtime on the install target looks up +# __vaDriverInit_1_22 and the dlsym() returns NULL. libva then reports +# "has no function __vaDriverInit_1_0" (its fallback search name) and +# vaInitialize() fails with -1. +# +# The driver itself doesn't link against libva.so — only the symbol NAME +# matters, and the name is computed at compile time from VA_MAJOR / +# VA_MINOR macros in . So all we have to do is point pkg-config +# at trixie's libva-dev headers; the link step still resolves -lva +# against the runner's libva (any version is fine — it's just for the +# linker to be happy, the result has no NEEDED entry for libva). +# --------------------------------------------------------------------------- +LIBVA_TRIXIE_VER="2.22.0-3" +TRIXIE_SYSROOT="$work/trixie-sysroot" +mkdir -p "$TRIXIE_SYSROOT" +for pkg in libva-dev libva2 libva-drm2; do + curl -sSLfo "$work/${pkg}.deb" \ + "https://deb.debian.org/debian/pool/main/libv/libva/${pkg}_${LIBVA_TRIXIE_VER}_arm64.deb" + dpkg-deb -x "$work/${pkg}.deb" "$TRIXIE_SYSROOT" +done + +# Rewrite the prefix in the .pc files so pkg-config returns -I/-L pointing +# inside the sysroot (Debian's pkg-config files default to /usr). +for pc in "$TRIXIE_SYSROOT"/usr/lib/aarch64-linux-gnu/pkgconfig/libva*.pc; do + sed -i "s|^prefix=/usr|prefix=$TRIXIE_SYSROOT/usr|" "$pc" +done + +# Symlink libva.so -> libva.so.2 inside the sysroot so the linker can +# resolve `-lva` against trixie's shipped runtime (no -dev symlink in +# the libva2 .deb). Same for libva-drm. +ln -sf libva.so.2 "$TRIXIE_SYSROOT/usr/lib/aarch64-linux-gnu/libva.so" +ln -sf libva-drm.so.2 "$TRIXIE_SYSROOT/usr/lib/aarch64-linux-gnu/libva-drm.so" + +export PKG_CONFIG_PATH="$TRIXIE_SYSROOT/usr/lib/aarch64-linux-gnu/pkgconfig:${PKG_CONFIG_PATH:-}" + curl -sSLfo libva-fourier.tar.gz \ "https://git.reauktion.de/marfrit/libva-v4l2-request-fourier/archive/${UPSTREAM_COMMIT}.tar.gz" tar xzf libva-fourier.tar.gz @@ -40,6 +81,17 @@ meson setup build \ -Db_lto=false meson compile -C build +# Sanity check: the produced .so MUST export __vaDriverInit_1_22 (not 1_23). +# Fail loud if it doesn't — otherwise the .deb installs but refuses to load +# on trixie and the bug is invisible until someone runs vainfo. +SO=$(find build -name 'v4l2_request_drv_video.so' | head -1) +if ! nm -D --defined-only "$SO" | grep -q '__vaDriverInit_1_22'; then + echo "FATAL: built driver does not export __vaDriverInit_1_22" + nm -D --defined-only "$SO" | grep -i vadriverinit || true + exit 1 +fi +echo "ABI check: $SO exports __vaDriverInit_1_22 (matches trixie libva 2.22)" + ROOT="$work/pkgroot" DESTDIR="$ROOT" meson install -C build diff --git a/debian/libva-v4l2-request-fourier/debian/changelog b/debian/libva-v4l2-request-fourier/debian/changelog index a22e9236b..81201b0f9 100644 --- a/debian/libva-v4l2-request-fourier/debian/changelog +++ b/debian/libva-v4l2-request-fourier/debian/changelog @@ -1,3 +1,21 @@ +libva-v4l2-request-fourier (1.0.0+r378+gc332d34-2) bookworm trixie; urgency=medium + + * Rebuild against pinned Debian trixie libva-dev (2.22.0-3) so the + driver exports __vaDriverInit_1_22 — the symbol trixie's libva + runtime looks up. Previous -1 build used the CI runner's Arch + libva (2.23.0) and exported __vaDriverInit_1_23, which trixie's + loader cannot bind: vaInitialize() returns -1 ("has no function + __vaDriverInit_1_0") and ffmpeg -hwaccel vaapi fails on startup. + * No source change; pure build-env fix. build-deb.sh now downloads + libva-dev / libva2 / libva-drm2 from Debian's archive, extracts + to a sysroot, and uses PKG_CONFIG_PATH to make pkg-config return + trixie headers regardless of what's installed on the runner. + * Hard sanity check: build fails if the resulting .so doesn't + export __vaDriverInit_1_22 (preempts the silent install-then- + refuse-to-load failure mode). + + -- Markus Fritsche Wed, 20 May 2026 18:00:00 +0000 + libva-v4l2-request-fourier (1.0.0+r378+gc332d34-1) bookworm trixie; urgency=medium * Bump to c332d34 — LIBVA-1 per-codec dispatch close. Pi 5 mixed