appimage error

[katakombi]

Hi there,

exciting project! However, none of the appimages seem to work on my system (Linux Mint 19.1)
I get this error:

./Doom\ \(PrBoom\)\ 1.9-r1-archlinux-x86.run 
./Doom (PrBoom) 1.9-r1-archlinux-x86.run: error while loading shared libraries: libglib-2.0.so.0: cannot open shared object file: No such file or directory

Do these appimages just work under certain distros (or arch as suggested by the name)?

thanks & greetings

[RazZziel]

Hi @katakombi, I'm sorry for the late reply!

They should work on all distros, but AppImage its no magic wand, we actually need to test the app on as many distros as possible :)

In this case, this AppImage was only tested on 32bit distros, so if you're trying a 64bit distro (understandable in 2019...), it may be missing some libraries, in this case at least libglib-2.0.so.0

I'm not sure I'll be able to work on it soon, so if you want to give it a try, I'm pretty sure it could be fixed by unpacking the AppImage and grabbing a more or less old version of the libglib-2.0.so.0 library, maybe from the lib32-glib2 ArchLinux package. In case more libraries are missing, they should be easy to identify with ldd.

[katakombi]

Ah great, thanks for your reply, @RazZziel ! I even suspected no answer at all as I saw the project seems inactive for the last few years or so. Yes, I am using 64bit, but I have a 32bit installation and I'm going to try ASAP.

I am working on a loosely related project: https://github.com/dolmades/dolmades-cli
I'm interested in using appimage, too, but I can't tell yet how reliably it will work in comparison of udocker.
Also I'd be thrilled to learn how you "stripped" down the dynamic linking dependencies in your containers, and how reliable this actually is. To my understanding you need to trace down the dependencies during a standardized run and add them to the appimage container. But this might break as soon as different code paths depending on settings, hard- or software are being run... which would not be too reliable.

Update: I tested on 32 bit and made some other game work. Doom has some other issue with locale it seems.... I will test a few more games soon

[probonopd]

Hey @RazZziel nice to hear from you after all those years. I know that I was a big proponent of making 32-bit AppImages back when many users were still running 32-bit systems, but as the years have passed most users have 64-bit capable machines those days, which is why we are focusing on native 64-bit AppImages these days. Even though you still can make (optionally) 32-bit ones.

For https://appimage.github.io/ we mandate 64-bit AppImages that run on the oldest still-supported Ubuntu LTS. Would be nice to see some more games there @RazZziel ;-)

[RazZziel]

I even suspected no answer at all as I saw the project seems inactive for the last few years or so.

Sorry about that! Life's been busy, and my time management skills lacking 😛

I am working on a loosely related project: https://github.com/dolmades/dolmades-cli

Man that's sweet, that's actually more or less how this whole thing started. I just wanted to play StarCraft at University, where we didn't have permissions to install wine, and wanted something I could distribute easily among friends, and so I created the StarCraft Appimage. After that I created some other Wine-based AppImage, like League of Legends (stopped working after some update broke Wine support), OnLive (long dead service), and probably some other stuff I've already forgotten.

Yes, I am using 64bit, but I have a 32bit installation and I'm going to try ASAP.

Shouldn't be needed, with some basic 32bit libraries it should work fine on a 64bit machine (for instance, libfuse2:i386 and libglib2.0-0:i386)

I'm interested in using appimage, too, but I can't tell yet how reliably it will work in comparison of udocker.

I haven't tried udocker myself, although using docker sounds like a bit of overhead. Regarding reliability I don't think it can get much more stable than an AppImage because it's really simple, it's just an ISO file (although I think they use squashfs now) with a binary that mounts and runs it. The only external dependency is (or was) libfuse2, and that's usually installed on all systems by default, and after that it's just a matter of including everything needed inside the package.

Also I'd be thrilled to learn how you "stripped" down the dynamic linking dependencies in your containers, and how reliable this actually is. To my understanding you need to trace down the dependencies during a standardized run and add them to the appimage container. But this might break as soon as different code paths depending on settings, hard- or software are being run... which would not be too reliable.

Yep, that's exactly what wineTrim does (I asume you got there reading Creating appimages from windows applications). It's tricky and not 100% foolproof, but it practice it has worked well for the games and apps I've packaged. Games are usually pretty constant in dependencies used throughout all runs, once the engine is loaded in single and multiplayer mode, it's not very likely that other dependencies will be needed, specially if the game doesn't have expensive configuration tweaks, like different renderers, etc. Complex applications are different, they may be more tricky to test to full coverage (they may want to load new libraries for importing and exporting, etc).

I know that I was a big proponent of making 32-bit AppImages back when many users were still running 32-bit systems, but as the years have passed most users have 64-bit capable machines those days, which is why we are focusing on native 64-bit AppImages these days. Even though you still can make (optionally) 32-bit ones.

I know, I know! The only reason these packages are 32bit is they haven't been updated since I migrated to 64bit years back 😛 nowadays I'd much rather deliver 64bit AppImages just to avoid having problems with libfuse2:i386 not being installed by default

For https://appimage.github.io/ we mandate 64-bit AppImages that run on the oldest still-supported Ubuntu LTS. Would be nice to see some more games there @RazZziel ;-)

Cool place, didn't know about it, I've been out of the loop for two long! The only thing I've been trying to package recently has been GammaRay, following the route of trying to PR AppImage support into the project's .travis.yml (provided I don't really have time to package and test new versions anymore), but I had some problem with linuxdeployqt not producing the expected output and put it on hold again