Appimage broken since version 0.6.8

[Dangonizer]

When starting the Appimage it immediately exits afterwards without any output.
Curiously enough getting commandline output with flags like -h still works, but the GUI never starts.
0.6.7 works fine, but any version above doesnt.
Flatpak version works fine even on current release.

System Info:
Operating System: Arch Linux
DE: KDE Plasma Version: 6.2.5
Qt Version: 6.8.1
Kernel Version: 6.12.9-arch1-1 (64-bit)
Graphics Platform: Wayland
GPU: AMD Radeon RX 6700 XT

[Rosalie241]

I'm unable to reproduce this on fedora KDE, and AppImages are provided 'as-is', I cannot 'fix' anything about them sadly, flatpak or native packages (AUR, Fedora COPR) are better options.

[Samueru-sama]

Hi @Rosalie241 I was recently requested to make an AppImage of a N64 emulator here and your project seems to be the only one that provides an AppImage, sadly it doesn't seem to work on some systems.

I can help fixing this, since I use a different method to makes appimages that makes them work on any linux system (even systems without glibc), examples 1 2 3.

I have some questions are really a bit off topic though, is there a specific reason this was coded into RMG?

https://github.com/Rosalie241/RMG/blob/master/Package/AppImage/AppRun#L6-L10

You can usually tell binaries to look for libraries using patchelf to set a relative rpath, set LD_LIBRARY_PATH or finally call the dynamic linker and pass the location of the libraries with --library-path and then launch the RMG binary (what I'm going to do here).

Same for the --shared-data-path, usually the application instead just needs to check for XDG_DATA_DIRS and all that needs to be done is add the AppDir/usr/share to that env variable.

EDIT: On the deploy script I also noticed that you have:

export LD_LIBRARY_PATH="$toplvl_dir/Build/AppImage/Source/RMG-Core"

Which I assume is because this way linuxdeploy can find the libraries there when it reads the elf to search for the libraries it needs?

[Rosalie241]

I have some questions are really a bit off topic though, is there a specific reason this was coded into RMG?

https://github.com/Rosalie241/RMG/blob/master/Package/AppImage/AppRun#L6-L10

Yes, those paths are hardcoded at build time into RMG-Core which RMG uses to find the required plugins alongside mupen64plus, see Config.hpp.in and Directories.cpp, so I added commandline arguments to override them for the AppImage because that directory changes each time an AppImage is run.

EDIT: On the deploy script I also noticed that you have:

export LD_LIBRARY_PATH="$toplvl_dir/Build/AppImage/Source/RMG-Core"

Which I assume is because this way linuxdeploy can find the libraries there when it reads the elf to search for the libraries it needs?

That's correct

[Samueru-sama]

Yes, those paths are hardcoded at build time into RMG-Core which RMG uses to find the required plugins alongside mupen64plus, see Config.hpp.in and Directories.cpp, so I added commandline arguments to override them for the AppImage because that directory changes each time an AppImage is run.

Would have been nice to have that as env variables instead, but not big deal and the reason is me being paranoid lol.

I already had an incident of a certain somebody that thought it was a good idea to have POSIXLY_CORRECT set system wide breaking something... So you can't even rely on bash behaving like it should lol.

sharun instead just reads the .desktop file in the AppDIr to find the binary to launch and if you need to set env variables it can do it on its own with this reading the .env file next to it.