AppImage does not start in version 1.10.1 -> 1.10.2

RetroArch Linux devices
#1

Greetings.

I have the “nightly” version, after the update, it does not start. I tried a new installation. It does not start either.

If I run it through terminal it gives this error:

$ '/home/lex/.appimage/RetroArch-Linux-x86_64/RetroArch-Linux-x86_64.AppImage' 
Setting $HOME to /home/lex/.appimage/RetroArch-Linux-x86_64/RetroArch-Linux-x86_64.AppImage.home
/tmp/.mount_RetroAARiDGU/AppRun.wrapped: symbol lookup error: /lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_date_copy

Running the log says the same thing:

Setting $HOME to /home/lex/.appimage/RetroArch-Linux-x86_64/RetroArch-Linux-x86_64.AppImage.home
/tmp/.mount_RetroAnU2tLZ/AppRun.wrapped: symbol lookup error: /lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_date_copy

I am running the log this way. I don’t know if it is correct with AppImage:

'/home/lex/.appimage/RetroArch-Linux-x86_64/RetroArch-Linux-x86_64.AppImage' --menu --verbose >> retroarch.log 2>&1

#2

I don’t know which appimage build is provided on the download page, but there seem to be two different builds. One that requires the latest ubuntu version as a base, and one that’s based on ubuntu 16.04. The latter can be downloaded here:

https://github.com/hizzlekizzle/RetroArch-AppImage/releases/tag/Linux_LTS_Nightlies

That one should be compatible with more Linux distros than the non-LTS build. Does it work for you?

I can´t run retroarch by linux (Ubuntu 21.10
#3

31 Jul 2020? It is slightly obsolete. (1.9.1)

I’m not sure, but I think an AppImage should work with any version of Linux, no matter the distro or version.

#4

Nope. AppImages only bundle some libraries. Things like glib, glibc and libstdc++ are not bundled because doing so can result in conflicts. If you build the appimage on a distro that has newer versions of those libraries, then it won’t run on older distros. In this case, if the appimage was built on latest ubuntu, then you require a distro that ships a version of glib that’s at least as new as the one shipped by latest ubuntu.

#5

Yes, but this is another case.

Update.

I downloaded the latest version of the stable and build repos. The ones that include Qt don’t start (with the error I commented before), the ones that don’t include Qt work perfectly. The PPA, Snap and Flatpak are all running smoothly.

#6

Hi. The Qt version of AppImage, also does not work in the current 1.10.2.

#7

I think this is a known thing and is why we have the Qt and non-Qt builds. That is, there’s no good way to bundle the Qt libs into the AppImage in a way that doesn’t conflict with system libs.

1 Like
#8

It’s a pity, I thought AppImage was the ultimate build, but it also gives problems. I will continue without Qt for now. Thanks hunterk.

#9

There is. But it takes some work :stuck_out_tongue: I have a couple projects that use Qt and I ship them as AppImage, but I had to create custom builds of Qt (using the KDE fork of Qt 5.15 with latest updates.) This is the dockerfile I made for this:

https://github.com/realnc/docker-images/blob/master/qtads/linux/Dockerfile

It uses Ubuntu 16.04 and thus it produces very compatible AppImages. It also builds OpenSSL. The AppImage itself needs to detect if the openssl version on the user’s system is compatible (it has to be 1.1.x). If not, the bundled version is used. This is done by appending this:

https://github.com/realnc/qtads/blob/master/appimage_openssl_hook

to AppDir/apprun-hooks/linuxdeploy-plugin-qt-hook.sh after running linuxdeploy without --output appimage. Then run it again with that flag:

https://github.com/realnc/qtads/blob/6f3eab56547a7430923d893232dd1798c7da56f5/qtads.pro#L470

With some effort, this kind of library version detection can be extended to libstdc++ as well, but I don’t think RA needs that.

#10

heh, feel free to point jdgleaver this way. Maybe he’ll follow suit.