Now run a decode test on the S01:
undefined reference to `aarch64_linux_get_cpu_flags' Why? Because libvpx’s assembly stubs for runtime detection expect an OS-specific function. On Linux ARM64, you need to ensure you built with the right AS (assembler) and that --enable-runtime-cpu-detect is paired with the correct --target . cross s01 libvpx
Cross-compiling turns that 45 minutes into . But only if you know the incantations. Step 2: The Toolchain Trap You need a cross-compiler. For S01 (Cortex-A53), I recommend aarch64-linux-gnu-gcc . Now run a decode test on the S01:
export CC=aarch64-linux-gnu-gcc export CXX=aarch64-linux-gnu-g++ export AR=aarch64-linux-gnu-ar export AS=aarch64-linux-gnu-as Then reconfigure. The build system needs to see the cross-tools for assembly. After make and make install DESTDIR=./rootfs , copy the .so files to your S01. Cross-compiling turns that 45 minutes into
./vpxdec example.vp9 -o output.y4m If you see Using CPU: ARM NEON , pour yourself a coffee. You just successfully tricked a complex x86 build system into emitting perfect NEON assembly for a low-power ARM core. Cross-compiling libvpx isn't hard because of the codec. It's hard because the build system wants to test CPU capabilities, and cross-compilation prevents that.
That’s where (System 01 / Stage 01) comes in. But today isn't about the hardware; it's about the codec that makes the web go round: libvpx (VP8/VP9). Cross-compiling this beast isn't just a ./configure --host=arm . It’s a dance with intrinsics, neon flags, and the ghost of floating-point quirks.