v0.3.1 Linux release binary links against FFmpeg 6 and fails on current Arch Linux

[Luquatic]

Hey, since I cannot comment on the AUR page I thought I'd place it here.

Summary

The v0.3.1 Linux release binary installs successfully through the AUR wallr-bin package, but cannot start on current Arch Linux because it is dynamically linked against the FFmpeg 6 ABI.

The AUR package downloads the upstream wallr-linux-amd64.tar.gz release asset unchanged, so the incompatible linkage appears to originate from the upstream release build rather than Yay or Pacman.

Environment

• Distribution: Arch Linux
• Architecture: x86_64
• Wallr release: 0.3.1
• AUR package: wallr-bin 0.3.1-1
• FFmpeg: 2:9.0.1-1
• glibc: 2.44+r24+g16be1518495f-1

Steps to reproduce

yay -S wallr-bin
/usr/bin/wallr --version

The package installation completes successfully.

Actual behavior

/usr/bin/wallr: error while loading shared libraries: libavutil.so.58: cannot open shared object file: No such file or directory

The executable requires these FFmpeg 6 libraries:

$ readelf -d /usr/bin/wallr | grep NEEDED
Shared library: [libavutil.so.58]
Shared library: [libavformat.so.60]
Shared library: [libswscale.so.7]
Shared library: [libavcodec.so.60]

Current Arch FFmpeg provides newer ABI versions:

libavutil.so.61
libavformat.so.63
libswscale.so.10
libavcodec.so.63

The installed file is unmodified:

$ pacman -Qkk wallr-bin
wallr-bin: 30 total files, 0 altered files

Its checksum also matches the executable extracted from the generated AUR package, ruling out local corruption or an accidental replacement.

A local Cargo build from the same Wallr version works correctly on Arch and links against the installed FFmpeg 9 libraries.

Likely cause

Wallr already depends on ffmpeg-next 9.0, so this is not caused by an outdated Rust dependency.

ffmpeg-next provides bindings and automatically links against the FFmpeg libraries available in the build environment. The release workflow currently runs on ubuntu-latest and installs:

libavcodec-dev
libavformat-dev
libavutil-dev
libswscale-dev

The resulting release artifact is therefore dynamically linked against the FFmpeg ABI provided by the Ubuntu runner. Upgrading ffmpeg-next alone would not make the binary portable or force a particular runtime ABI.

The AUR package currently declares no dependencies, but adding Arch's current ffmpeg package alone would not resolve the major ABI mismatch.

Expected behavior

The published generic Linux binary should either:

• Run without depending on the build runner's FFmpeg ABI.
• Be labeled as distribution-specific with documented runtime requirements.
• Be accompanied by a source-based installation option for distributions with different FFmpeg versions.

Possible solutions

One option would be a release-only bundled FFmpeg build using the ffmpeg-next build/static support. This should be implemented as an explicit release feature so normal source builds can continue using the system FFmpeg.

The resulting artifact should be checked with readelf or ldd to ensure it no longer requires system libav*.so versions. Codec availability, NVDEC/VAAPI support, artifact size, and FFmpeg licensing obligations would also need verification.

Other possible approaches include:

• Publishing distribution-specific release assets.
• Providing a source-based AUR package that compiles against Arch's current FFmpeg ABI.
• Testing release artifacts in clean target containers with at least wallr --version.

[programmersd21]

fixed in 0.3.2