The standard advice has been to use Ubuntu 14.04 for building AppImages as it was the oldest version of Ubuntu that was still supported.
Since support for 14.04 finished in April 2019 should we now be using Ubuntu 16.04 for building our AppImages? I would hate to think that I inadvertently bundled a library with a security risk because I built my AppImage on an OS that is no longer receiving security updates.
Cheers,
Chris
I am also interested by this question.
I am trying to find the best build distro in order to maximize running compatibility. Our software is a 3D mesh editor, and it is linked to several third party libraries that are not standard of the classic linux distros, which clearly not help to setup the build.
I target old distros like Ubuntu 14.04 and also CentOS 7.6. I made the following “Distro Build vs Run matrix”, where rows are the distro used for the build and construct the AppImage, and the column is the distro on which the software is ran:
| BUILD | CentOS7.6 | Ubuntu14.04 | Ubuntu16.04 | Ubuntu18.10 |
|---|---|---|---|---|
| CentOS7.6 | OK | usr/lib/libgtk-3.so.0: undefined symbol: g_log_structured | usr/lib/libgtk-3.so.0: undefined symbol: g_log_structured | Segmentation fault (core dumped) |
| Ubuntu14.04 | gtk theme problems | OK | OK | gtk theme problems |
| Ubuntu16.04 | glibcXX missing | glibcXX missing | OK | OK |
| Ubuntu18.10 | glibcXX missing | glibcXX missing | glibcXX missing | OK |
| glibc | 2.7 | 2.19 | 2.23 | 2.27 |
Considering the remark made by cgarry, I think my choice is going toward Ubuntu16.04, which imply the loss of the compatilibity with CentOS7.6. It is a shame, but I clearly fail in my attempts to solve the display problems created by the gtk theme system.
Any feedback is welcomed.
The author of an AppImage needs to decide which systems to target.
For practical reasons, we generally recommend to target the oldest distribution still-supported LTS release of Ubuntu, which currently is xenial. Based on our experience, this covers the majority of users.
thank you for your support.
There is exceptions, which is unfortunately a bad news for my domain:
Xenial comes with glic 2.19, however the Visual Effects Society Technology Committee recommends to software devs to link against glibc 2.17. The reason is that most VFX and animation movies studios are using CentOS distros. And even the CentOS 7.7.1908, which has been released this year, comes with glibc 2.17. Which means that software build on Xenial will not run on CentOS distros.
Yes, I understand - this is a perfectly valid use case for building the ingredients that go into an AppImage on an older build system, e.g., CentOS 7.
We are building the appimagetool AppImage on CentOS 6 for this reason.
Regarding the matrix you posted above, binaries built on systems with newer glibc versions will never run on target systems with older glibc versions (unless you bundle everything, down to glibc and ld-linux.so, which we genereally don’t recommend because it may be considered bloated).
But binaries built on build systems with older glibc versions are expected to run on later systems
So, the question is, why don’t the binaries built on CentOS 7.6 run on Ubuntu. Your table hints at Gtk related issues. Possibly bundling a slightly different set of libraries may be able to resolve this issue.
Can you provide the build that you made on CentOS 7.6 for analysis? If you don’t want to post it publicly, you can also mail it to me (address mentioned here).
Bundling everything could actually be a solution. The AppImage currently weights 73Mb, if bundling everything would make something less than 200Mb I am ok with it, but I don’t know how to proceed. VFX workstations usually have plenty of disk space and they are used to host bigger software, like Autodesk Maya for instance.
But of course I prefer smaller images, so that would be great if you would analyse the following image, made using CentOS 7.6:
www.rizom-lab.com/setups/LINUX_SETUP/Beta/RizomUV.2019.0.99.gde7e02c.master.2019-09-25.CentOS-7.6.AppImage
Right. Some people object to the idea (especially for small applications on heavily hardware-constrained systems), but in your use case bundling everything might actually be a good trade-off between size and reliability. If you want to experiment with going that route, check out the Scribus AppImage - it bundles everything including glibc and the ld-linux loader, which should make it possible to run it on CentOS 7 even if it has been built on a much newer system.
The key lies in the following two files, that are working hand-in-hand to pull off the trick:
Let me know if you don’t understand what they do. In the meantime, I will have a look at the AppImage you posted.
Running this on Ubuntu 18.04.2 LTS gives
me@host:~$ '/home/me/Downloads/RizomUV.2019.0.99.gde7e02c.master.2019-09-25.CentOS-7.6.AppImage'
(rizomuv:18473): Gtk-WARNING **: 19:47:28.342: Theme parsing error: <broken file>:1:0: Failed to import: Error opening file /tmp/.mount_RizomUJoAidr/usr/gtk.css: No such file or directory
yet the gtk.css is actually stored somewhere else, namely in /tmp/.mount_RizomUJoAidr/usr/bin/gtk.css (note the additional /bin).
So when I do:
./RizomUV.2019.0.99.gde7e02c.master.2019-09-25.CentOS-7.6.AppImage --appimage-extract
mv squashfs-root/usr/bin/*css squashfs-root/usr/
./squashfs-root/AppRun
then I do not get this error and the window looks like this:
Actually the css file was a (failed) attempt to remove the problem that is visible on your screenshot (have a look a the menu bar, see how the menu items are stretched). The css file was there to unset all properties coming from gtk themes, so that the application get only the gtk default settings, but it doesn’t work even if the css file is correctly placed. BTW the warning you get with the css file doesn’t harm.
However you don’t get the segfault on your Ubuntu 18.04. Which means that a little something on my Ubuntu 18.10 creates a crash on startup, so the problem may be unlinked with the AppImage setup. I’ll look at this tomorrow.
But I doubt that this image would run on a older Ubuntu, like the xenial, for now I get
usr/lib/libgtk-3.so.0: undefined symbol: g_log_structured
when running it on xenial and trusty.
By the way thank for the link to scribus, it may help. I see the flag -unsupported-bundle-everything, I suppose it is understood by linuxdeploy (non-qt) as well.
You need to do the other stuff as well, like manually bundling all of the glibc related files and writing a custom AppRun script that executed the payload application through the bundled, patched ld-linux like shown.
According to ABI Navigator, g_log_structured was added to libglib.so (GLib) in version 2.49.3. As per https://github.com/AppImage/pkg2appimage/blob/master/excludelist we have been thinking that we can safely assume libglib-2.0.so.0 to come with every system and hence it would not need to be privately bundled, although we might be wrong on that one. Maybe it is necessary to be bundled inside the AppImage? Trial and error may be needed here.
I am on the not bundling everything way and after bundling libglib.so in the image created on CentOS 7.6 and running on Ubuntu 16.04, I got:
rizomuv: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined symbol: g_spawn_async_with_fds so I bundled also libgio-2.0.so.0 and it fixed the problem on Ubuntu 16.04.
However on Ubuntu 14.04 I got:
Gtk-Message: 17:01:57.843: Failed to load module "overlay-scrollbar"
Gtk-Message: 17:01:57.848: Failed to load module "unity-gtk-module"
rizomuv: symbol lookup error: /tmp/.mount_RizomUTk0vMR/usr/lib/libgtk-3.so.0: undefined symbol: g_type_check_instance_is_fundamentally_a so I bundled libgobject as well,
but I got rizomuv: symbol lookup error: /tmp/.mount_RizomUttM6l3/usr/lib/libgtk-3.so.0: undefined symbol: pango_renderer_set_alpha, so I bundled libpango as well,
but I got rizomuv: symbol lookup error: /tmp/.mount_RizomUC88s1J/usr/lib/libpango-1.0.so.0: undefined symbol: fribidi_get_par_embedding_levels_ex, so I bundled libfribidi as well,
The application then loaded but I got bunch of gtk theme errors messages and
Gtk-Message: 17:37:11.739: Failed to load module "canberra-gtk-module"
Gtk-Message: 17:37:11.745: Failed to load module "canberra-gtk-module"
GLib-GIO-Message: 17:37:24.963: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications.
without any font visible (all gliphs where replaced by small squares). And when trying to open a file selector dialog the application exited with this error code:
(rizomuv:124609): GLib-GIO-ERROR **: 17:37:25.002: Settings schema 'org.gtk.Settings.FileChooser' does not contain a key named 'sort-directories-first'
Trace/breakpoint trap (core dumped)
On Ubuntu 18.10: the application still crash when the main frame is shown. But the license activation dialog is displayed correctly before. Which mean that there is a hope that a modification in the code may solve the problem. In the meantime, you shown me that it runs on the Ubuntu 18.04.2 so I will see if I get ride of my 18.10 as it is EOL and take the 18.04.X in place.
| BUILD | CentOS7.6 | Ubuntu14.04 | Ubuntu16.04 | Ubuntu18.10 |
|---|---|---|---|---|
| CentOS7.6 | OK | gtk crash | gtk theme problems | Segmentation fault |
| Ubuntu14.04 | gtk theme problems | OK | OK | gtk theme problems |
| Ubuntu16.04 | glibcXX missing | glibcXX missing | OK | OK |
| Ubuntu18.10 | glibcXX missing | glibcXX missing | glibcXX missing | OK |
| glibc | 2.7 | 2.19 | 2.23 | 2.27 |
I need some time to decide what I do now. Any feedback is welcomed.
I stopped trying to bundling more libraries and tried another way to fix the gtk theme problems.
I finally found a way to fix the “gtk theme problems” by defining the env variable GTK_DATA_PREFIX to a non existent directory.
As a reminder, the gtk theme problem comes from the fact that the current theme located in system directory of a Ubuntu 18.04, is loaded by default by a gtk3 library that comes from a older Ubuntu, like the 14.04. This create important display problems. So a hammer style solution is to prevent gtk3 to load the theme located in the system directories. A possible way to do this is to define the GTK_DATA_PREFIX to a directory that do not exist (see https://developer.gnome.org/gtk3/unstable/GtkCssProvider.html) and run the image:
GTK_DATA_PREFIX=xxx RizomUV.AppImage
in that way, the hard coded gtk default theme is charged instead of the current system’s theme. And no more display problems. The obvious drawback is that the application do not follow the color theming requested by the user. In my case it is acceptable.
However, I would like that the user not have to enter GTK_DATA_PREFIX like presented above. I tried these ways:
1- Renaming the AppDir to _AppDir and create a AppDir script that defines GTK_DATA_PREFIX and call _AppDir but I get execv error: Exec format error when running the image
2- Renaming my exe binary from rizomuv to rizomuv_ and created a script rizomuv that call ./rizomuv_ but ./rizomuv_ is not found
3- Get rid of the AppRun binaries and define my own AppRun script. But some I couldn’t succeed to create one that correctly run my application (some env seem to be missing).
So my question: Is there a proper way to define env variables using the AppRun binaries, or would it be possible to recreate a AppRun script that does the minimal necessary stuff to run my app binary correctly ?
Hi
I finally opted for defining the env variable directly in my App just before the gtk initialization. It is not really nice, but it works. The incompatible gtk themes file present on the newer system are correctly ignored.
At the end, and regarding the initial question of this thread, I would answer that my distribution choice for building remains Ubuntu 14.04. This choice is motivated by the fact it still increase the compatibility on relatively old distributions, especially the CentOS ones that uses old version of glibc. However, the gtk theme compatibility problem shown that embedding all dependent libraries in the image didn’t solve everything when running the image on newer systems. Some native configurations files, present on the newer brought problems because these file are no longer compatible with the old embedded libraries. So, if the compatibility with old distributions wouldn’t be an issue, I would certainly switch to Ubuntu Xenial.
