AppImage not running

I downloaded the AppImage from here. I’ve made the AppImage executable by changing the properties but still the it doesn’t run after double-clicking. What should I do? I’m pretty new so don’t know if missing something silly.

Which Linux distribution?
On Debian / Ubuntu / Mint (and probably many others), you can check the executable permission by right clicking on the file, then opening the “Permissions” tab (you can also set / modify permissions here.

permissions.png
If that’s correct and it still won’t launch, try rebooting.

you may need to install libfuse2 for it to work: https://github.com/AppImage/AppImageKit/wiki/FUSE

If the above suggestions don’t help, and you are comfortable entering terminal commands, open a terminal window and enter

cd Downloads/
./audacity-linux-3.1.3-x86_64.AppImage

substituting whatever directory you downloaded it to and the exact file name.

This will allow us to see any error messages (even when it’s working properly there are usually lots of non-fatal errors reported!), such as missing permissions or missing support packages.

Also, some libs were not included, made it to fail to run on some distros, like Porteus 5 x64 (running Xfce):

Output:
findlib: libjack.so.0: cannot open shared object file: No such file or directory
audacity-linux-3.2.1-x64.AppImage: Using fallback for library ‘libjack.so.0’
findlib: libportaudio.so: cannot open shared object file: No such file or directory
audacity-linux-3.2.1-x64.AppImage: Using fallback for library ‘libportaudio.so’
/tmp/.mount_audacikyNRUq/bin/audacity: error while loading shared libraries: libthai.so.0: cannot open shared object file: No such file or directory

Version tested: audacity-linux-3.2.1-x64.AppImage

This is a common problem with ultra-lite versions of Linux. Many libraries and resources are removed to keep the distro light and small, which has the downside that they are not able to support some applications without first adding additional libraries that are present in mainstream distros as standard.

I recall, some years ago, installing Audacity on Puppy Linux. It took ages to figure it all out, but eventually I got it working. After that, I installed a minimal install of Debian, added a windows manager (“openbox” if I recall correctly) and built Audacity from source - this was much easier and worked better than the Puppy Linux version.

If you want to stick with Porteus, I’d suggest that you stick with the official modules that they provide. On the other hand, if you want to use Audacity, I’d suggest that you install a mainstream OS.

I thought the main idea behind AppImage was to be system agnostic, otherwise we’re back to the original problem on Linux: packages built by basically every distro, dependency manager, broken compatibility among systems, broken applications after system update, etc.

When I build an AppImage I use TinyCore as the reference because if it runs there, it’s very likely it’s going to run everywhere.

Thanks!

Shoot me if I’m wrong, but I thought the whole point of AppImage was to bundle dependencies with the executable…

It is not recommended to package “everything” in an AppImage. Best practices say that the AppImage needs to include all libraries and other dependencies that are not part of all of the base systems that the AppImage is intended to run on.

This is the list of packages that the developers of AppImage recommend excluding from an AppImage package: https://github.com/AppImageCommunity/pkg2appimage/blob/master/excludelist
The documentation describes this as:

This file lists libraries that we will assume to be present on the host system and hence should NOT be bundled inside AppImages.

(I’m not an expert on packaging, but my understanding is that these are mostly low level libraries that are used by the base system of common desktop distributions and will likely create conflicts with the base system if loaded by an AppImage.)
Ultra-light distros may not include everything on that list, so will not be able to run some AppImages without first installing additional libraries.

Lol, I wrote windows software for years and, after the nightmare of ‘dll hell’, got to the point of distributing absolutely everything, including C runtimes, along with the executable. I understand the downsides of this; such as shared libraries not being updated in step with the system, but the software in question was centrally managed and regularly updated, so it wasn’t a problem in this case.

My subsequent efforts, on various unices, avoided linked binary interfaces wherever possible, preferring various kinds of IPC (streams, sockets, shared memory) using background services. I often found these far more efficient and far simpler to manage, even at v high bandwidth.

…which, I realise, is the philosophy of much of the audio system I’m currently messing with, and also (I suspect) snap interfaces, etc…

From this document:

libGL.so.1
# The above may be missing on Chrome OS,

libpcre.so.3 # Missing on Fedora 24, SLED 12 SP1, and openSUSE Leap 42.2

libwind.so.0 # Missing on openSUSE LEAP 42.0

libjack.so.0
However, this library is missing on Fedora-WS-Live-31-1-9

The very existence of this document (and the fact it grows over time) is a clear proof it’s wrong. It would be way simpler to simply pack everything, not assuming anything. It would guarantee compatibility with any distro, but more than that: it would guarantee compatibility with any version of the packages installed in the system.

Hah! Exactly what I thought. Also, the term ‘workaround’ features quite a lot. Is dynamic linkage a failed experiment and should we just compile everything into one binary? After all, the container approach goes even further, often as not including the OS itself.

Maybe you guys should be having this discussion with the developers / documenters of AppImage rather than here. As far as I can see, the Audacity developers are simply following “best practices” as described in the AppImage documentation.

:+1: