I tried installing an AppImage by copying it to my home directory and executing it from there. It failed with a missing library. Seems a bit odd for an AppImage, I thought they were supposed to just work and could be executed from anywher (it was Prusa Slicer btw).
Thanks.
AppImages are advertised this way but really they’re just a random guess of what it’s bundled with and what it’s going to try get from the host. They’re also usually compiled against an Ubuntu LTS and Fedora is far too new for them to run.
1 Like
Hi @mogplus8,
This is a known issue for the Prusa Slicer AppImage where components of the AppImage are incomplete.
Thanks @pluto and @miker256. I never did like appimages anyway, they just seemed to me to be contrary to the Linux ethos. But it seemed to be the only way to get Prusa into SB. Other than trying to build a Flatpak…
:-\ Ian
AppImages do not need to be installed. They are just downloaded, made executable, and run.
Thanks for reporting this issue.
Which library exactly?
Most AppImages assume certain system-level libraries such as glibc to come with every target system (Linux distribution).
Most AppImages do not bundle everything but only those things which cannot be reasonably expected to be already present on every mainstream Linux distribution (such as Ubuntu, Fedora, and openSUSE).
Apparently your Silverblue system is lacking some of those basic libraries that normally can be expected to ship by all Linux distributions by default.
You should be able to install the missing library using the methods provided by your Linux distribution.
Please don’t spread FUD and wrong technical information.
The author of an AppImage has to decide which target systems (distributions) to target, and has to privately bundle everything that does not come with those distributions by default.
Most authors of AppImages refer to https://github.com/AppImage/pkg2appimage/blob/master/excludelist. This file lists libraries that we will assume to be present on the host system and hence should not be bundled inside AppImages.
This is completely wrong, as binaries compiled on older build systems must run on newer systems (or else it is a bug); whereas binaries compiled on newer systems will NOT run on older systems.
It is called “backward binary compatibility”. And it works the same way on macOS and Windows, too.
Every AppImage that gets listed on https://appimage.github.io/ is tested to run on the oldest still-supported LTS release of Ubuntu. Other distributions are encouraged to maintain binary compatibility to that.
What is “the Linux ethos”? Linus Torvalds, the creator of Linux, said about AppImage:
This is just very cool.
I finally got around to play with the “AppImage” version of +Subsurface, and it really does seem to “just work”.
It not only allows for a project to create a complex Linux application (in the case of subsurface, one that uses very recent library versions that many distributions don’t even have available yet) that works on multiple distributions, you don’t even need to really even install it. Download a file, mark it executable, and run it.
It comes with its own little embedded compressed ISO filesystem that gets mounted and contains all the required libraries.
Sure, it means that the end result is much bigger than a distro-native binary would be, but if you want a way to build applications for your users without limiting them to a particular distribution, or having to build fifteen different images, it really looks like it works very well.
AppImage has, among others, these advantages:
- One app = one file = super simple for users: just download one AppImage file, make it executable, and run
- No unpacking or installation necessary
- No root needed
- No system libraries changed
- Works out of the box, no installation of runtimes needed
- Optional desktop integration with
appimaged - Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
- Can optionally GPG2-sign your AppImages (inside the file)
- Works on Live ISOs
- Can use the same AppImages when dual-booting multiple distributions
- Can be listed in the AppImageHub central directory of available AppImages
- Can double as a self-extracting compressed archive with the
--appimage-extractparameter - No repositories needed. Suitable/optimized for air-gapped (offline) machines
- Decentralized
This horrendously fails to account for incompatible versions between distros.
I’ve pointed out nothing incorrect, perhaps you should just fix the technical shortcomings of appimages if you don’t want them to be posted publicly, calling FUD because someone said something you don’t like is not going to get you many friends around here.
Except they DON’T. You can hope for that all you wish but it doesn’t make it true.
Relies on FUSE. Gross. This also promotes a heavily dangerous practice.
You need to for desktop integration. Said .desktop files get left behind when the AppImage is removed.
We’ve already established this isn’t true.
Even more gross.
1 Like
Why is this relevant?
and yet it doesn’t.
Backwards binary compatibility doesn’t really exist in the Linux world. Everything moves too quickly. Microsoft is paid to ensure backwards compatibility and has a runtime system, oh and Microsoft controls and writes every library on the system so they can do that.
macOS apps are bundling their libraries anyway and the system rarely changes. Oh and Apple does not really care about old applications no longer working.
As an example I’ve downloaded the OnlyOffice AppImage.
./DesktopEditors-x86_64.AppImage
./DesktopEditors: symbol lookup error: /lib64/libhogweed.so.5: undefined symbol: __gmpn_cnd_sub_n
This is terrible and caused by the AppImage targeting Ubuntu 18.04. I’m on Fedora 31, if the AppImage targets Fedora 31, it’s now likely going to be broken on Ubuntu 18.04.
And no, it’s not fucking sane for apps to be shipping their own copy of GnuTLS either if you’re going to suggest that.
No, it doesn’t. A binary compiled against a certain version of glibc is expected to run on all subsequent versions of glibc, or else glibc is broken and needs to be fixed.
You wrote:
“random guess” is factually incorrect. A lot of work has been going into determining the “lowest common denominator” of what can be assumed to be “just there” across Linux distributions.
I wrote “or else it is a bug”.
FUSE works out of the box on all mainstream desktop Linux distributions I have checked.
Desktop integration is purely optional. The optional appimaged daemon can handle desktop files for you, including automatic removal when the AppImage is removed. But the Linux desktop is seriously lacking behind macOS in this area; I agree that having to move around desktop files is not nice.
The Linux desktop should learn from Mac OS X how to suck less at system integration:
Actually, it is. Run a Ubuntu Live ISO and try it with an AppImage.
Because someone thought AppImages were “contrary to the Linux ethos” when in fact the very creator of Linux likes them.
Then let’s point out the offenders and make them fix it. Linus Torvalds is very strict about the kernel not breaking userspace. But userspace breaks userspace “all the time”, which imho is not desirable.
Everything can move as quickly as it wants, as long as newer versions of libraries can still run binaries compiled against older versions of said libraries. This is sound engineering practice, nothing else.
Please report this bug to the OnlyOffice project.
The LibreOffice AppImages, in contrast, have been working very, very well for me. You should give them a try. Those guys understand about backward binary compatibility.
Full ack. GnuTLS is a system-level library. It should be provided and updated by the operating system. For this to work, GnuTLS must make sure that applications compiled against earlier versions of GnuTLS will continue to run using subsequent versions of GnuTLS. If it doesn’t, then it’s imho broken.
I’m not saying everything is perfect - in fact there are many Desktop Linux Platform Issues that need to be addressed at their core (rather than being taking for granted and being worked around).
That doesn’t help the user with the broken app that it’s not “supposed” to be broken. It should never be able to be broken in the first place.
Libraries should be able to make large changes. Unless you want to become some kind of dictator where only probonopd can tell library creators what they can and can’t change. AppImages sound like a cool feature (trying to copy the macOS style application) but the implementation is absolutely dog shit awful.
Seriously… FUSE???
I thought AppImages are supposed to run everywhere? That’s the point right, that the packager hasn’t got to cater for distribution differences? right?
Yes, a world without bugs would be better than a world with bugs.
How would one go about making this happen, short of not using the infrastructure that comes with the operating system at all, and bundling private copies of everything (like Flatpak and Snap do)?
They can. Just make a new major version, and have OSes ship the old major version for some time (e.g., 5 years), to give developers time to move to the new major version in the meantime; a.k.a. “deprecate gracefully”.
What’s wrong with it, and how would you like to mount a disk image without needing root permissions instead?
Well, “everywhere” as in “everywhere the packager has targeted and tested”.
For more information, please refer to
https://docs.appimage.org/introduction/concepts.html
You’re welcome to contribute improvements to the implementation.
So you don’t even know how Flatpak works. Great.
Nice. I’m sure application developers are really looking forward to testing their applications on two dozen distributions.
Then don’t use disk images.
I’m not going to reply any more.
Why should I? It does not do what I need, and besides I could never get it to work on the types of systems I am running.
But I know enough to understand that instead of using basic system-level libraries from the operating system, it downloads and installs runtimes with its own versions of said libraries, hence working around rather than solving the issue of binary compatibility.
Then don’t use disk images.
How do I make “one app = one file” then?
I’m not going to reply any more.
That’s unfortunate, but your choice.
At this point I must be biased, but seriously @probonopd have to turn any thread into a “promotion” for your project? There are many pros and cons (even if you always say no to the cons), but this I don’t think is the best place to leave the topic on the initial question.
@mogplus8 , can you mark thi thread as “solved” (if your problem has already been solved), to close this? Thank you.
You could always install it as a regular package.
John M. Harris, Jr.
Splentity
Wow! I really seem to have stirred up a hornet’s nest with what i thought was a simple question. How to install an appimage in SilverBlue. I tried just copying it to a directory in my home folder, but that failed. The library it couldn’t find was libGLU.so.1. I tried entering a toolbox and installing libGLU.so.1 there but it said mesa-libGLU-9.0.0-17.fc30.i686 was already installed. Not sure but is that the 32 bitt version? I removed it anyway and then tried sudo dnf install libGLU.so.1 and it offered to reinstall the same package. So now I’m not sure how to proceed.
@JohnMH how would I install it as a package? There is only an AppImage and a tar.bz2 download available. Can it be installed from the tar.bz2?
BTW when I mentioned the “Linux ethos” what I meant was that a developer did not need to include any standard libraries in their package as they are all (or should be) already provided by the OS. If they aren’t then the user can install them to the OS using the standard package manager. So for an application to include all the libraries that are already available to it via the OS (and creating a load of duplication) seems to me to be contrary to the “ethos” of Linux as I understand it.
Flatpak, as I understand it, does a similar thing by providing all (or most) of the common libraries in a runtime, so not in the OS itself, which helps keep the OS in a stable state and allows immutability for the basic OS.
Thanks,
1 Like
I just successfully installed AppImageLauncher on Fedora Silverblue. I just downloaded and installed the .rpm and it worked just like it does on other distros.