Build an AppImage targeting Xenial #347
Labels
Comments
Closed
whitequark
changed the title
Ho yes, I really think so. I'm on Arch Linux. I don't want to install on my system every needed libs. I tried to make an AppImage from within Docker but it doesn't start. Is there any progress on this from your side? Flatpack is maybe a better choice but it looks more complex to setup. (I have no experience either) Here is the Dockerfile I made but the extracted AppImage is not running on my system. |
@probonopd, could you check what is wrong? |
|
Please upload the non-working AppImage for analysis. |
|
The resulting AppImage inside the container is here. |
|
Do you know which resource it is trying to load? |
|
I can't test it right now. |
|
I also can't test it right now ;-) |
|
I ran it but I can't read the output... I think you should take a look when you have the time for this. ✌️ |
|
Thanks for the log. Could it be that the application crashes if
It's always best to have the author of an application join the effort, because usually it's mcuh easier for them to know what might be going on. |
|
Yes, it would crash if it cannot find the resources directory. It looks for either |
Since we have |
|
I'd say you don't need the usr/ hierarchy inside the AppImage at all. |
|
Well, it's best practice to have a |
|
If you added the lookup for |
probonopd
added a commit
to probonopd/solvespace
that referenced
this issue
Apr 21, 2019
|
Note that I still do not think that AppImage is a good idea in its current form, and I have no plans to distribute them. But I can't stop other people from doing it, and adding support for relative lookup in |
|
Looks like we may be getting somewhere: |
I try launch it under Debian 9.x, but it failed Terminal output |
|
Needs further testing. seems to be coming from solvespace/src/platform/platform.cpp Line 241 in fa66229 @whitequark can you give us some hint what may be going wrong here? |
|
@probonopd Exactly what it says in the assertion text. Your PR was buggy and I fixed it in master already. |
|
Sorry for my buggy PR and thanks for fixing! 👍 (You can guess that I am not a C++ expert by any stretch of the imagination.) |
|
@Symbian9 a fixed AppImage for d103974 should appear in a few minutes on https://github.com/probonopd/solvespace/releases, would be great if you could give it a try again. Thanks! |
@probonopd, I just tested latest build & it still failed on start Terminal output |
|
I think the theme parsing stuff is not fatal, but the |
|
Looks like we have something that launches now :-)
Is it any good? |
|
@probonopd No, it does not look good at all. You built with |
|
Thanks @whitequark. Please check again, are we getting there? |
|
Yes, this is better. But the copy of GTK you are shipping is broken. E.g. the little arrow pointing to submenus is missing in your build: |
|
As the AppImage does not ship a GTK theme nor GTK resources such as images, I think it is using what it finds on the host. This is how it looks for me on Xubuntu 18.04:
|
|
In that case you should not ship the rest of GTK either and use what's on the host as well. This is exactly the kind of problem with AppImage that I have warned about before. |
|
The problem with GTK is that even after it has reached a major version number (such as 3.0) they are making binary incompatible changes. If I delete
So I think for now the current set of bundled libraries is at least functional, albeit with cosmetic glitches. If we find out which additional items we need to bundle, we can do that. |
In theory (see this for details), after GTK has reached 3.22, it should be upwards ABI compatible. Are you building against 3.22 or later? |
|
3.18.9, the one that is in xenial. |
|
Wait. That doesn't add up. Specifically, the requirement for Xenial was because SolveSpace required new GtkGLArea features. However, in this comment, @ebassi said:
So, you should talk to the GTK people to figure out why that doesn't work. I don't think shipping an AppImage with broken UI theming is acceptable and if you do so I request you to prominently state that it is not supported by upstream. |
|
I am not interested in doing anything that is not supported by upstream... which means we'll have to find a solution ;) |
|
Let's check if my line of thinking is correct:
Question: With "GTK" only We are currently bundling Which of those are covered by the guarantee that "a binary built with GTK+ < 3.22 is guaranteed to run against GTK+ ≥ 3.22", and hence do not need to be bundled? cc @ebassi |
|
That's a good question. Looking at my local build, these libraries definitely need to be bundled: We also have the following libraries, which are both our direct dependencies and dependencies of GTK... ... and things get a bit weird there. All these libraries are guaranteed to be present on the host system, since GTK needs them, and GTK will load them into our address space. But one problematic case would be if GTK loads a version of one of those libraries with a different soname. In that case, if the library in question does not use symbol versioning (fontconfig, expat and freetype do not), it might result in a situation where GTK is linked against libfreetype.so.7, both it and libfreetype.so.6 are loaded into our process by the dynamic linker, and it's a coin flip as to which one ends up getting called. To handle this, out of that list, we should only bundle the libraries that do use symbol versioning, namely: so that if that case does arise, things break quickly and in an obvious way (missing library at startup) as opposed to slowly and in a complicated way (memory corruption or crash at runtime). Note that when bundling you of course should not use full sonames but masks like |
|
Oh, and an important one: Does
also mean that a binary built with GTK+ 3.18.9 is guaranteed to run against GTK+ > 3.18.9 but < 3.22? |
|
Okay, there's a lot of ground to cover, here.
Theming is problematic. CSS selectors were made part of the ABI/API in GTK 3.22; theming in general is not considered part of the API outside of the CSS selectors exposed by GTK widgets, which are part of the documentation and thus remain stable. The only theme that GTK guarantees to be working is Adwaita, because it's shipped by GTK itself. For third party themes: it is possible to ship different versions of the theme for the releases of GTK that didn't have any stability guarantee for the CSS selectors; not every theme does that, though, so third party themes will likely break. Additionally, GTK does not ship an icon theme, so if you're missing assets then you may be missing an icon theme with those assets from your bundle.
GTK 3.x ships only two shared libraries:
anything else is a dependency of GTK; so if you used a specific version of ATK, Pango, Cairo, HarfBuzz, libX11, GNU libc, to compile GTK, then you need to ship those libraries as well, because GTK may be using a symbol added in Cairo 1.15, so you cannot ship Cairo 1.12. Of course, if you built your application against GTK 3.18 and all its dependencies and then you upgrade to GTK 3.22 and all its dependencies then the application will continue to work—assuming none of the dependencies in question broken binary compatibility. Most of the dependencies of GTK are maintained by the same people, so they follow the same conventions; other dependencies are mostly stable/low level, so their ABI doesn't really change. Of course, this only goes in one direction. If, for instance, GTK 3.18 depends on Pango 1.40, and GTK 3.22 depends on Pango 1.44, it usually means that GTK 3.22 needs new symbols from Pango; this means that you can run your application built against a version of GTK with a newer version of GTK, but you cannot run your application built against a version of GTK with an older version of GTK. I know this is basic stuff, but I wanted to make sure we are all on the same page. GTKmm is another thing entirely, and since the GTK team does not maintain bindings I honestly cannot say anything about them; the C++ bindings are, as far as I know, ABI stable, and since they provide API wrappers around GTK, then they have to follow the same convention of forward compatibility as GTK itself.
I don't understand the distinction you're trying to make. A binary built against GTK 3.18.9:
To sum up:
|
|
Thank you for the clarification @ebassi. I will try to find what this means for bundling vs. not bundling the concrete dependencies in question.
|
The library is ABI stable; the CSS selectors for third party themes were not part of the interface exposed to application developers, regardless of major or minor version. |
|
How do we proceed from here? Make an AppImage that bundles everything? |
|
No, follow #347 (comment). |
|
Looking at https://github.com/AppImage/pkg2appimage/blob/master/excludelist we should already be doing this but I am gonna check again. |
|
Theming gets fixed if we do not bundle libgdk-3.so.0 and libgtk-3.so.0 but then it will not run on non-Gtk systems anymore. Acceptable or not? |
probonopd
added a commit
to probonopd/solvespace
that referenced
this issue
Sep 5, 2019
If bundle If so, then there as solution just provide two versions:
|
|
I think you should bundle Gtk/Gdk, even if this means loosing theming support, so it works EVERYWHERE forever. Please provide only single AppImage. The entire point of having it is just to JUST WORK anywhere. Adding two options will be confusing to people, and will be asking question all the time. @Symbian9, the naming is confusing. The one with "Gtk" in its name, actually doesn't have Gtk, and the one without "Gtk" in its name, actually ships with gtk inside. Nono. Too confusing and unnecessary. Plus if you provide the version without the Gtk, project dies, and you trie to run it 25 years from now to read some obscure slvs files, you are screwed, because you don't have access to the Gtk dependencies anymore. Bundle everything. As of theming, maybe the note at the total end of this guide: https://docs.appimage.org/packaging-guide/manual.html#bundling-gtk-libraries could help? You can always make things work better in the future, and possibly have a detection script inside AppImage that tries to to use system gtk first, and if not then use its own, based on detection, trying to run it (and dynamic linker failing) or just user flags. |
That's not possible.
As of today, we provide official Snap packages. If you insist on having just one distro-indepenent package like that, then there won't be an AppImage at all.
No software will work "forever" without some maintenance. For example, at some point desktop Linux will migrate to Wayland. |
I am not sure I understand what you are saying. AppImage IS a distro-independent package. Properly packaged AppImage app will have no dependencies on the host system at all other than the kernel APIs and cross process APIs via sockets or shared memory. And OpenGL driver from the host if you want to use it.
I was hearing that for the last 10 years. |
When I decide to use sarcastic comments from nerds to decide on the roadmap instead of looking at the planned future directions of the supported platforms, I'll make sure to ask you for advice. |
Even if majority of Linux desktop installations will migrate to Wayland, X11 will still be used for very very very long time. |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As discussed many times before, having a downloadable, distro-independent Linux binary would be useful. Per #344 (comment), this AppImage cannot be built against Trusty, but Xenial should be fine.
The text was updated successfully, but these errors were encountered: