Qt is smart enough to figure out the target Qt version for native plugins.
However, Qt is _not_ smart enough to figure out the target Qt version for
QML imports, which causes all kinds of funny breakage when you start running
Qt 5 applications from Qt 6 ones and vice versa.
So, do some minimally invasive surgery to make different Qt versions pick up
different QML import path variables, so they don't mess with each other.
This is kind of very cursed, but what can you do.
QtMultimedia 6.6.0 would select dynamic VAAPI on linux, then warns
during build (even though it chose this on purpose):
> QT_FEATURE_vaapi is found but ffmpeg doesn't include vaapi,
> however dynamic symbols resolve is possible
The nuisance warning was fixed for 6.7 and backported to 6.6.1:
https://codereview.qt-project.org/c/qt/qtmultimedia/+/517333
However, tracing it helped me figure out why vaapi actually wasn't
working: nix doesn't end up with an rpath such that dlopen("va")
can actually find libva.so in the nix store, thus failing at runtime:
> qt.multimedia.plugin: loading backend "ffmpeg"
> qt.core.library: "/nix/store/i9fkjks6dfjj1p9qvj5633sxbrf5rbd8-qtmultimedia-6.6.1/lib/qt-6/plugins/multimedia/libffmpegmediaplugin.so" loaded library
> qt.multimedia.ffmpeg.libsymbolsresolver: Start VAAPI symbols resolving: 39 symbols
> qt.core.library: "va" cannot load: Cannot load library va: (va: cannot open shared object file: No such file or directory)
> qt.multimedia.ffmpeg.libsymbolsresolver: Couldn't load VAAPI library
This is now the default recommendation upstream for linux platforms
> https://doc.qt.io/qt-6.6/qtmultimedia-index.html#ffmpeg-as-the-default-backend
> In this release the FFmpeg framework is set as the default backend on
> Windows, macOS, Android, and Linux except Yocto distribution.
> The version shipped with Qt binary packages is FFmpeg 6.0
> and is tested by the maintainers.
libXrandr is required to compile support QT_WINDOW_CAPTURE_BACKEND=x11
Specify a deployment target of 10.13 to avoid errors due to clang’s
having a hard-coded check for 10.13 when using them (even though it
implements them with `posix_memalign`, which is available on earlier
versions of macOS).
QtWebEngine tries to build with clang 14, which links libc++ 14, but the
top-level libc++ on Dariwn is libc++ 16. This results in a crash during
the build, which is fixed by building with the default stdenv.
