Having AppImage Launcher installed makes AppImages created with the Go runtime fail to start

[quyykk]

AppImages created with this runtime fail to start if the AppImage Launcher is installed, which is less than ideal: endless-sky/endless-sky#7476

> chmod +x ./endless-sky-x86_64-v0.9.16.1.AppImage 
> ./endless-sky-x86_64-v0.9.16.1.AppImage 
execv error: No such file or directory

yet another log:

(process:33191): GLib-CRITICAL **: 17:39:35.719: g_file_test: assertion 'filename != NULL' failed
execv error: No such file or directory

Uninstalling the AppImage Launcher makes the AppImage runnable again. A lot of distros ship with the launcher installed by default, so this is pretty problematic.

Thanks!

[probonopd]

@TheAssassin do you have an idea why this might be? Does AppImageLauncher make any particular assumptions about the runtime? E.g., does it make the assumption that the runtime is dynamically linked?

[TheAssassin]

Most likely an issue caused by static linking. Please tell me what the actual differences are to the one appimagetool embeds.

[TheAssassin]

In any case, @quyykk please open an issue over at AppImageLauncher and link it to this one. We can always close it.

[probonopd]

The runtime used in go-appimage is statically linked and hence does not like to be invoked through ld-linux.

[TheAssassin]

I know, but is this really the only change?

[probonopd]

It also uses zstd compression and may not have all --appimage-... command line options implemented which the default runtime has.

[TheAssassin]

Please provide a link to the code and, if separate, the build infra. I'll have a look.

Short technical background: AppImageLauncher's bypass-binfmt helper needs to explain to the runtime where the AppImage really is. All "released" types (1 and 2) lack a specified way to do so. The current technique to inject those data is to LD_PRELOAD a library that hooks into a set of common glibc tools. Linking everything including libc statically prevents us from hacking the paths.
(Yes, I know that's not a great method and is prone to errors, but it's been by far the most reliable way (!) so far...)
It is all explained in detail here.
Should we make the static runtime the default in the near future (and I'd like to collaborate on that, maybe on some hackweek(end)), we should specify a better bypass way. I guess TARGET_APPIMAGE could be reactivated and later be standardized.

[probonopd]

Please provide a link to the code and, if separate, the build infra.

https://github.com/probonopd/static-tools/tree/master/src/runtime

Should we make the static runtime the default in the near future (and I'd like to collaborate on that, maybe on some hackweek(end))

Yes, let's do that!

[TheAssassin]

So the quick fix is to quit linking libc statically. You can link libraries statically by selection. I think in your Makefile case (for the record, plain Makefiles are annoying and just create additional work even when using tools like pkgconf), you'd have to pass the paths of your libraries and remove the corresponding -l<lib> parameter. It'd be easier to use pkgconf --static [...].

[quyykk]

TheAssassin/AppImageLauncher#518 this issue seems to exist already