search

AppImageCrafters / appimage-builder

GNU/Linux packaging solution using the AppImage format
MIT License
304 stars 58 forks source link

Issue with bundling (or not bundling) `libwayland-*` #255

Open TheBrokenRail opened 2 years ago

TheBrokenRail commented 2 years ago

The issue is that both the AppImage and the graphics driver can depend on the Wayland libraries.

If you do bundle libwayland-*, then the AppImage can crash if the system's graphics driver requires a newer libwayland-* than the AppImage (which is why I created #236):

/lib/aarch64-linux-gnu/libEGL_mesa.so.0: undefined symbol: wl_proxy_marshal_flags

However, if you don't bundle libwayland-*, then the AppImage can crash if the AppImage requires a newer libwayland-* than the system:

zenity: symbol lookup error: /tmp/.mount_minecrbaFrQa/usr/lib/x86_64-linux-gnu/libgdk-3.so.0: undefined symbol: wl_proxy_marshal_flags

The only good solution I can see to this is to build the AppImage on a super old OS and not bundle libwayland-*, so that the OS's libwayland-* is always newer than the one the AppImage was built with. But this removes one of appimage-builder's main advantages IMO, that you don't need to build on a super old LTS (unlike linuxdeploy).

What do you think?

azubieta commented 2 years ago

I working on AppRun modules which should provide a way to opt-in certain binaries and runtime environment variables depending on the host system.

Right now I've use them for glibc and glibstdc++ but it seems that we will need one for libwayland too. To implement it we need a way of reading the version from the libwayland library.

appimage-builder modules support branch: https://github.com/AppImageCrafters/appimage-builder/tree/feat/apprun_v3