AppImage (was: a linux statically linked version)

Look what happened to smc. They had only dynamically linked binaries for linux. For what ever reason, the project died, the source became uncompilable and the binaries became unusable.

Yea sure, by jumping through hoops you could restore it.... A statically linked binary should remain playable for a very long time with no maintenance. Quintus mentioned that statically linking could more easilly be part of the build process then appimages or flatpacks.

Yea, build a statically linked version and put it in a simple archive, just as long term insurance that it will not just vanish. Maybe Nintendo will send you a nasty email tomorrow, maybe the lead developer will be hit by a bus, whatever. In theory, it should require little additional effort.

A good example is gridwars. The binary was made in 2006.... in 32bit.... and it still works... even on arch.

[xet7]

@pirate486743186

TSC does not use any graphics, audio, levels etc from Nintendo games. Nintendo has no reason to send nasty email.

I have not yet figured out how to make AppImage.

There is some flatpak code in repo, but I have not tested it yet.

PRs welcome.

[refi64]

Afaik you cannot fully statically link binaries on Linux that require OpenGL because the drivers need to be dynamically loaded.

[Quintus]

Look what happened to smc. They had only dynamically linked binaries for linux. For what ever reason, the project died, the source became uncompilable and the binaries became unusable.

It may be uncompilable currently, but with enough effort it should be possible to get the original SMC to compile again. The main problem is the old SDL1 dependency probably. I would rather suggest to simply use TSC instead, though.

Yea sure, by jumping through hoops you could restore it.... A statically linked binary should remain playable for a very long time with no maintenance. Quintus mentioned that statically linking could more easilly be part of the build process then appimages or flatpacks.

I am a friend of static compilation, but for other reasons. With TSC I have repeatedly seen people struggling with getting the correct versions of all dependencies for the sake of developing TSC, so for newer projects, I try to set up the build system so that it fetches the required versions and compiles them in statically. This has the user-visible side effect you describe.

However, as refi has pointed out:

you cannot fully statically link binaries on Linux that require OpenGL because the drivers need to be dynamically loaded.

I have not fully explored this area yet, but my cursory research on the topic suggested that statically linking anything related to Linux’ lowlevel graphics libraries is risky and can produce problems. This is why I usually leave things like mesa, libx11, and libgl as dynamic dependencies. Their ABI seems stable enough to warrant this.

For TSC, it will be more work to provide a (mostly) statically linked version, because the project was only ever written with dynamic linking in mind. It seems unlikely that I will do so in the nearer future; but there is some code in the build system for building Flatpaks or AppImages as far as I know -- this is more an area for @refi64 than for me. As these bundle all dependencies, including dynamically linked dependencies, in a container, these containers should in theory work on every system that supports Flatpak or AppImage.

Quintus mentioned that statically linking could more easilly be part of the build process then appimages or flatpacks.

What I meant to say by this is that for me it is easier to figure out static linking than dealing with AppImage or Flatpak, because I barely used any of the latter, not even as a user. Often when I tried to use a Flatpak, something did not work. That doesn't make me want to try the developer side of this. Getting static linking right is a matter of unrolling the dependency tree and then including CMake build instructions for all recursive dependencies. Since copyright law requires you to unroll your dependency tree anyway at least mentally so that you can get license compatibility right, this is not so much more work for me. But still it is some work, and TSC currently is not a high priority for me.

Maybe Nintendo will send you a nasty email tomorrow, maybe the lead developer will be hit by a bus, whatever.

We do not use any Nintendo material in TSC. As for myself, I am still alive as far as I can see. But I agree that TSC's bus factor is low. You’re welcome to increase it -- PRs welcome.

-quintus

gridwars didn't use any assets from geometry wars, he still got an unpleasant email.
Nitendo has a reputation of doing dumb shit with it's lawyers...

Yea sure, low level stuff are either very stable, either people will create wrappers for them. These are not a problem. (for example, there's a project to implement opengl on top of vulcan)

for the original gridwars binary, these are the dependencies libgl libstdc++5 alsa-oss
Distros are indeed still providing stdc++5 and oss for legacy stuff.

TSC currently is not a high priority for me.

It seams what happened with smc started happening here. The lead developer will slowly drift away.... The bus is here...

I thought that static linking just required a compilation option and make would do it's magic.... Then an appimage is the easiest solution. You don't need to modify the binaries or source code. The appimage tool modifies the final binaries and harvested libraries so that they are portable. I don't remember exactly, it does some hacky looking changes with the linker. An appimage, is basically just an iso file pretending to be an executable, it loads it self with fuse, then launches a program inside. It's the simplest of container formats. There's no sandboxing or any container technology involved.

[kenderipa]

Any news on the AppImage front?

[xet7]

@kenderipa

It would need someone with time to figure out how to make the AppImage. Is there some tool or script for that purpose?

[kenderipa]

I'm not creating AppImages myself, however, there are some tools I know about.
https://github.com/ivan-hc/AppImaGen
https://github.com/ivan-hc/ArchImage

This guy is using them: https://github.com/ivan-hc/ivan-hc

Or there's official documentation:
https://github.com/AppImage/AppImageKit/wiki#-how-do-i-bundle-my-application-as-an-appimage