Regarding running i386 AppImages on x86_64 architecture #1400

Hi everyone,

I’ve been trying to package some old i386 applications/games as AppImages, but I’m not satisfied with the current approach of targeting either x86_64 or i386 exclusively. In reality, if I bundle all the necessary i386 runtime libraries, the AppImage should run on an x86_64 system even without i386 support enabled. To achieve this, I need to modify the program’s rpath and interpreter to make it fully portable and work seamlessly with both 32-bit and 64-bit systems when double-clicked or executed.

However, when packaging this as an AppImage, a major issue arises: the hardcoded relative interpreter path (/lib/ld-linux.so.2). While I can use patchelf --set-interpreter to modify it, the interpreter path doesn’t accept environment variables like $ORIGIN (unlike rpath). For the main application binary, this isn’t a big deal since it can still handle . or .., but for the AppImage or AppRun, it’s a problem. The mount path changes every time, making it impossible to specify a fixed path for ld-linux.so.2 in AppRun.

The current dilemma is this: if I modify AppRun with patchelf, it won’t support dynamic paths. I’ve seen some experimental projects that attempt to address this, but unfortunately, they only support 64-bit architectures, so they’re not helpful for our case.
like this:https://github.com/corsix/polyfill-glibc/blob/main/docs/Relative_interpreter.md

If I abandon the binary AppRun and instead use a shell script named AppRun, the AppImage itself (as a binary) still hardcodes /lib/ld-linux.so.2. Of course, we could enable i386 libraries system-wide to ensure /lib/ld-linux.so.2 exists, but that clearly goes against the spirit of AppImage—the whole point of AppImage is to avoid installing dependencies, isn’t it?

This isn’t a problem report or a feature request—just a discussion to see if anyone has better ideas to make this work.

Personally, I think the solution lies in making AppRun dynamically recognize $APPDIR/lib/ld-linux.so.2 while ensuring the AppImage binary can still execute properly. But I’m not sure how to achieve that.