Library issues with Linux AppImage observed at runtime
See original GitHub issueA large number of reports have been received (#458, #470, #481, #504, #583, #618, #625, #631, #692) relating to AppImage support on Linux. This is a consolidation ticket to cover the general problem of Linux AppImage support.
To Reproduce
Reports are most common when using third party binaries (e.g., Pillow), or GUI libraries that have third party binaries (e.g, PySide2/6). However, problems have also been observed with Toga apps when deploying on recent versions of Linux (e.g., using Ubuntu 22.04)
The problem manifests in one of two ways.
A failure to find dependencies during build time:
-- Deploying dependencies only for ELF files --
Deploying files in directory /app/Hello World/Hello World.AppDir/usr/app_packages/PySide2
WARNING: Not an ELF file: /app/Hello World/Hello World.AppDir/usr/app_packages/PySide2/_config.py
WARNING: Not an ELF file: /app/Hello World/Hello World.AppDir/usr/app_packages/PySide2/QtScxml.pyi
WARNING: Not an ELF file: /app/Hello World/Hello World.AppDir/usr/app_packages/PySide2/QtCore.pyi
Deploying dependencies for ELF file in AppDir: /app/Hello World/Hello World.AppDir/usr/app_packages/PySide2/QtXmlPatterns.abi3.so
Deploying dependencies for ELF file /app/Hello World/Hello World.AppDir/usr/app_packages/PySide2/QtXmlPatterns.abi3.so
ERROR: Could not find dependency: libshiboken2.abi3.so.5.13
Missing dependencies at runtime:
>>> /home/criaz/repos/briefcase-613/hello/linux/hello-0.0.1-x86_64.AppImage
Traceback (most recent call last):
File "/tmp/.mount_hello-9Pm4Um/usr/lib/python3.9/runpy.py", line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/tmp/.mount_hello-9Pm4Um/usr/lib/python3.9/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/tmp/.mount_hello-9Pm4Um/usr/app/hello/__main__.py", line 4, in <module>
main().main_loop()
File "/tmp/.mount_hello-9Pm4Um/usr/app/hello/app.py", line 27, in main
return hello()
File "/tmp/.mount_hello-9Pm4Um/usr/app_packages/toga/app.py", line 272, in __init__
self.factory = get_platform_factory(factory)
File "/tmp/.mount_hello-9Pm4Um/usr/app_packages/toga/platform.py", line 41, in get_platform_factory
from toga_gtk import factory
File "/tmp/.mount_hello-9Pm4Um/usr/app_packages/toga_gtk/factory.py", line 1, in <module>
from .app import App, DocumentApp, MainWindow
File "/tmp/.mount_hello-9Pm4Um/usr/app_packages/toga_gtk/app.py", line 8, in <module>
import gbulb
File "/tmp/.mount_hello-9Pm4Um/usr/app_packages/gbulb/__init__.py", line 1, in <module>
from .glib_events import *
File "/tmp/.mount_hello-9Pm4Um/usr/app_packages/gbulb/glib_events.py", line 12, in <module>
from gi.repository import GLib, Gio
File "/tmp/.mount_hello-9Pm4Um/usr/app_packages/gi/__init__.py", line 40, in <module>
from . import _gi
ImportError: /usr/lib/libgio-2.0.so.0: undefined symbol: g_module_open_full
The specific libraries involved vary between reports, but common themes include:
- references to GDBM
- References to glib or gio - these seem particularly common on c2022 Linux distress (e.g., Ubuntu 22.04)
- Apps that use Pyside2 or Pyside6
Expected behavior
It should be possible to build and run Linux AppImages on any version of Linux.
Environment:
- Operating System: Linux; most common on non-Ubuntu, or Linux distros released c2022
- Python version: Any
Additional context
There are likely a number of underlying problems that all have similar manifestations. It seems highly likely that we’re not driving LinuxDeploy correctly. Given the number of options and plugins that exist for linuxdeploy, and the complexity of binary compatibility on linux, that’s not entirely surprising. We need a better understanding of how LinuxDeploy should be working, and then test on a wider range of configurations and systems.
#717 is related to this; it’s possible that some of the reported problems may be avoided by adopting a manylinux base.
Issue Analytics
- State:
- Created a year ago
- Reactions:3
- Comments:22 (13 by maintainers)
After a lot of investigation, it appears that #756 addresses the bulk of the GTK-related issues running on “recent” Linux releases; #761 addresses the issues related to binary modules. On that basis, I think this ticket as a “locus of Linux packaging issues” has reached the end of its useful life. If any new issues arise with Linux packaging, we can investigate further based on those specific reports.
#759 looks like it won’t work as a generic solution; however, there’s a documentation only solution in #761.
I’ve also reported the issue upstream: linuxdeploy/linuxdeploy#204