The current AppImageLauncher process of bypassing binfmt_misc involves extracting the runtime from the AppImage in question into a memory buffer, patching out the magic bytes and launching it from there with an LD_PRELOADed library. As you can imagine, we need to tell this patched runtime where the real binary is to be able to mount the FUSE filesystem correctly.

This library is a bit of a hack. It hooks some functions we know the runtime uses (read: the old type 1 and the type 2 one that AppImageKit features) and that way it can reliably fix all kinds of function calls that point to the AppImage.

This has worked exceptionally well over the last few years. However, with a static runtime, i.e., a static binary, there is no LD_PRELOAD feature that could be used.

For upcoming runtimes, we could specify some kind of other method that can be used to reliably tell the runtime where the real binary is. In fact, the current type-2 runtime already features a TARGET_APPIMAGE environment variable (which AppImageLauncher used prior to version 1!), which could be improved a bit. However, AppImageLauncher needs to know that this feature exists for sure.

My suggestion: let's make TARGET_APPIMAGE or a similar approach that works in the scenario I described part of the runtime's specification. Any spec-complying runtime needs to expose such a feature. Also, let's bump the runtime version so that it is easy to discover that the feature is there for third-party tools. Last but not least, we won't break any compatibility by retrospectively changing the specification.

Side note: of course, I'd rather avoid this annoying workaround. However, it's the best and most reliable way I came up with so far to bypass binfmt_misc. They do not have a feature built-in that could be used and as far as I can see have no interest in improving this. Also, it would take years for such a feature to reach end users anyway, since this is a kernel level problem.