MelonDS appimage crashes when a specific joystick is selected #2261
Comments
|
Does it happen with the 1.0 RC flatpak (from the flathub beta repo)? |
|
I didn't know I could install that one, let me try. gdb logs: $ gdb ./squashfs-root/usr/bin/melonDS For help, type "help". Temporary breakpoint 1, 0x00005555555d4a90 in main () Thread 1 "melonDS" received signal SIGSEGV, Segmentation fault. Quit anyway? (y or n) y |
The flatpak version of the flathub beta repo works without any issue. |
|
I guess it must be some weird issue with the SDL2 from Ubuntu 22.04 that the appimages are built with. Probably not much that can be done other than hoping they update it or switching to a newer distro for the builds. |
|
Ohh, well yes, i have Debian 13 installed because SDL2 works really bad in Debian 12, in Debian 13 all my devices works. I will close the issue with the hope of the switching to a newer distro for the builds will be sooner than later. |
|
The current AppImage built using linuxdeploy. I don't like linuxdeploy and a lot of the old appimage tooling, they basically make appimages that depend on the host libraries and want you to build on ubuntu 20.04 to prevent the glibc incompatibility issues. Which just complicates things since a lot of modern build dependencies are not found on 20.04 For example, I maintain this AppImage of dolphin-emu that I recently switched to bundle all dependencies and build on Artixlinux, this is the build part on Artixlinux: https://github.com/pkgforge-dev/Dolphin-emu-AppImage/blob/main/.github/workflows/Dolphin_sharun.yml#L22-L72 And this is what it used to be when built on ubuntu which neede a zillion ppas and hacks to get it to build: https://github.com/pkgforge-dev/Dolphin-emu-AppImage/blob/main/.github/workflows/blank.yml#L22-L79 Because we bundle all the dependencies it means the appimage will be bigger, so in this case the appimage ends up being ~160 MiB instead of the 100 MiB it used to be. The good news is that the AppImage is truly portable as it works on any linux system, even on musl distros and distros that have namespaces disabled. iirc there are only two tools that deploy appimages with all dependencies, those are go-appimage and sharun. The later is the one I like to use since it has a mode with strace that finds most of the dlopened libraries, however I often still need to bundle several libs manually though. |
|
Yeah I'm not entirely happy with the way that is set up either. Having to build on some old distro to get sufficiently old libraries and then downloading and running some binaries that may change at any time feels like a very fragile solution to me. I have considered switching the Linux builds to using vcpkg like the Windows and macOS ones, that one all the dependencies can be built and linked statically into the binary, technically removing the need for having an AppImage at all, though maybe should still provide one if that's what people are used to, maybe built with some other tooling. Changing over to the arm64 runners to reuse the same build stuff as the x86_64 builds again reminded me of wanting to do that, because linuxdeploy just dies with some filesystem exception on the arm64 runner and I can't reproduce it locally and don't know what to do about it. |
|
@nadiaholmquist Yeah building statically is the perfect solution, but if I'm not mistaken you can't statically link libraries like vulkan and opengl. But still even statically linking some libraries helps a ton. For example this mpv appimage that bundles all the libs as well used to be 80 MiB, I later then switched to using the mpv build script, which links ffmpeg statically and that reduced the size of the AppImage to 22 MiB. And yes even if you make a fully static binary, shipping it in an AppImage is still ideal, because you can for example have working delta updates with appimageupdate, if you make a directory nex to the AppImage with the name of the AppImage + |
|
I use the appimage only for gamed because:
I can say it in summary: I don't want to go through the trouble of configure the emulator more than one time, I want to configure the emulator once for each game and then just have to launch the game, without changing anything again. If all that is provided i don't care about the name of how this mechanism is called. Today, the closest thing to what I want is called appimage. |
|
Here's an AppImage build using vcpkg dependencies, the way I was considering doing it for CI builds. I would appreciate if one of you would give it a try and tell me if it works fine on your systems. |
Trying on ubuntu 20.04: This is because the The fix is easy and I could PR this hopefully within next week, since all that needs to be done is bundle whats missing and set a few env variables. Also using patchelf I find that the This actually isn't needed, a better method is to instead bundle the dynamic linker and call the dynamic linker, pass the location of the bundle libraries with |
|
The image work ok on Debian 13, not problem detected on my system. However, @Samueru-sama is a kind of appimage guru and he can tell you where the appimage won't work and where it will work, just by knowing which system and which tool you generated it with. He has already tested many mechanisms and generated many images. He simply has the advantage of experience and that is very important when it comes to predicting possible anomalies behaviors. |
Yeah I mean the AppImage I tested will work for about ~85% of linux users, since most linux users are either on ubuntu 24.04, Fedora 40+, Archlinux, etc, etc. This will not work on ubuntu 20.04 which iirc it is the equivalent of debian stable, it won't also work on distros that don't have glibc at all like alpine or chimera, which doing what I was talking about would fix. |
|
@nadiaholmquist I'm looking forward to have the vcpkg builds setup, that way I can gladly do the rest of steps to make the appimage fully be able to run anywhere like here. |
I use the appimage from 1.0 RC in Debian 13 Trixie (uncompressed). I have 3 controllers and only the Logitech G29 Driving Force Racing Wheel cause a melonDS crash instantly after being selected. The flathub version 0.9.5 works without a problem with that controller, although of course melon doesn't see it as what it really is, nor do I expect it to do that way. I think it would be pointless to detect it for what it is, because games wouldn't be able to take advantage of this controller anyway.
In Debian 13 there are missing dependencies to be able to compile melonDS directly from source code, so that it can be ruled out if the error is caused by the appimage, from melon, or being an upstream error from SLD.
The segmentation fault:
The text was updated successfully, but these errors were encountered: