Emulator doesn't start on Steam Deck

[Eduxki]

Is there an existing issue for this?

• I have searched the existing issues

Affected Build(s)

All builds since hack to make Luigi's Mansion 2 run better

Description of Issue

Since that hack is available to apply for games that got non-static fps to make them work better, All builds including nightly linux image artifacts don't start the emulator, at least using Steam Deck, Lemonade or whatever is called that other citra fork works.
A ver si le puedes echar un ojo Señor Pablo, de paso estaría bien que se añadiera un valor aproximado de referencia al hack para juegos con fps dinamicos, ya que tal y como está ahora los usuarios tenemos que adivinar que juegos necesitan ese hack y descubrir que valor hace que funcione mejor el juego, podeis esconder el hack en lugar de estar a la vista en la configuración como hacían el equipo A del emulador hermano de Citra que tuvo que apoquinar a N 2 millones y medio de pavos que tenían mientras seguían pidiendo mas dinero con dos cojones.
Yours truly, your Holiness Eduxki, first of his name.

Expected Behavior

Run

Reproduction Steps

Double Click

Log File

Game Over

System Configuration

CPU:
GPU/Driver:
RAM:
OS:
Steam Deck

[getBoolean]

I can confirm this is still an issue on r608383e
Works with Lime3DS 2118.2

However, I was unable to get CTGP-7 working with Lime3DS or the older r4780a71 release

[jvalecillos]

I can confirm that this issue affects not just the SteamDeck but also any Linux distribution using glibc < 2.38 (for example, SteamOS 3.5.19, Ubuntu 20.04 LTS and 22.04 LTS, Debian 12 and 11, and Linux Mint 21.3 and 20.3).

As of now, the latest two releases are affected: r5115f64, r608383e.

The issue seems to have started when the Docker image used by CI was replaced due to this commit: PabloMK7/build-environments@f2467ba.

A possible solution would be to revert those changes and use a Docker image with an Ubuntu version that is still compatible with the main LTS or stable Linux distributions. While the latest version is Ubuntu 24.10, it's not an LTS release, and Ubuntu 20.04 (which was previously used) is still supported until April 2025.

For more details, you can refer to the recommendations from linuxdeployqt (the tool used to create the AppImage) regarding binary compatibility:

We recommend targeting the oldest still-supported Ubuntu LTS release and building your applications on that. This way, the resulting binaries should run smoothly on newer (but not older) systems (Ubuntu and other distributions).

For completeness, if anyone stumbles upon this while searching for the error, here's how it looks when running from the CLI:

./citra-qt.AppImage
/tmp/.mount_citra-n0AVVL/AppRun.wrapped: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by /tmp/.mount_citra-n0AVVL/AppRun.wrapped)

[jvalecillos]

As I’ve been asked about a workaround in my PR for the fix, I’m providing the information here for reference.

To build the app manually, you'll need to have git and docker installed on your system, along with enough available space on your hard drive (approximately 5 GB for both the Docker image and the repository itself). Additionally, be prepared to spend at least 30 minutes on the build process, based on my testing.

Here's how to build the app locally:

#!/bin/sh -ex

# Clone the repository recursively to include dependencies
git clone --recursive https://github.com/PabloMK7/citra.git PabloMK7-citra
cd PabloMK7-citra

# Build the app using Docker
docker run --rm -v "$(pwd)":/app -w /app \
 -e OS=linux -e TARGET=appimage -e ENABLE_COMPATIBILITY_LIST_DOWNLOAD=false \
 pablomk7/build-environments@sha256:bfde277bdaba9bdb516664dfae051c0c4deeec9c2dd33a5246684cf0391e8e1b \
 /bin/sh -c "git config --global --add safe.directory /app && ./.ci/linux.sh"

If the build is successful, the newly created app will be located at build/bundle/citra-*.AppImage.

This method works because I was able to find the image digest from the previous Docker image version used by the CI before the issue was introduced. The sha256 refers to that digest.

[Senni2127u]

Issue described by jvalecillos in the associated PR seems to be resolved when running 3.6.19 SteamOS since Valve updated the Arch Linux distribution and kernel to a newer version.

[jvalecillos]

@Senni2127u You're right. While I haven't tested it, the latest stable release likely uses a newer version of glibc. However, the issue still persists on other Linux distributions, as mentioned earlier. We could either open a new issue for that and close this one, or simply update the description.