ABI guarantees around runtimes

[Cameron Gutman]

> On Apr 15, 2021, at 11:37 AM, Robert McQueen <rob at endlessos.org> wrote:
> 
> 2. The far trickier problem comes from derived runtimes. GL drivers and
> some other binaries which appear in extension points are often built at
> the same time as the runtime, or they could be rebuilt after a symbol
> has been added to the runtime, acquiring an implicit dependency on the
> new release. In the case there is a derived runtime (eg GNOME or KDE)
> that re-uses binaries or recipes from the Freedesktop SDK, you can have
> the situation that a new base runtime upgrades a core library, so the
> extensions might implicitly depend on some new symbols or interfaces,
> but the /derived/ runtime has not been updated/rebuilt to include these
> symbols. This means these extensions are "from the future" compared to
> the derived runtime, and they could at best fail to load, or prevent
> anything from working. Although typically the extensions have a limited
> interface surface (a handful of libraries rather than the dozens in the
> whole platform), it only takes once glibc itself versions all symbols
> and so it's very easy to trip over this situation even with relatively
> minor platform updates.
> 

I have run into this exact scenario more than once. Here is a concrete
example of the problem here.

My Flatpak (com.moonlight_stream.Moonlight) is a Qt app that uses the
org.kde.Platform//5.15 runtime and org.freedesktop.Platform.VAAPI.Intel
extension for VAAPI hardware video acceleration on Intel platforms. The
trouble is that libva is baked into the KDE runtime while the VAAPI
driver is included in the Freedesktop VAAPI extension.

VAAPI's ABI compatibility works by using versioned entrypoints like
__vaDriverInit_1_7, __vaDriverInit_1_8, __vaDriverInit_1_9, etc. in the
drivers. This allows newer libva versions to support older VAAPI drivers
by trying each supported __vaDriverInit function in descending order.

The problem is that the VAAPI drivers have only a single entrypoint that
corresponds to the version of libva they were built with. For example,
a driver built for libva 2.10 will have __vaDriverInit_1_10 and no other
entrypoints. In other words, libva is backwards compatible with older
VAAPI drivers, but the VAAPI drivers are only _forwards_ compatible with
equal or newer libva versions to the one they were built with.

When the Freedesktop runtime and org.freedesktop.Platform.VAAPI.Intel
were updated to libva 2.10 [0], I had the VAAPI extension built for libva
2.10 (which had __vaDriverInit_1_10) running with libva 2.9 (which only
knows about entrypoints up to __vaDriverInit_1_9) from the KDE runtime.
This version mismatch broke hardware acceleration in my app for a couple
weeks until org.kde.Platform//5.15 was rebuilt for unrelated patches.

This same breakage happens every time the Freedesktop folks update the
version of libva used to build org.freedesktop.Platform.VAAPI.Intel.

[0]: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/4262 <https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/4262>

Regards,
Cameron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/flatpak/attachments/20210420/e28301c0/attachment.htm>