Godot: Building AppImages for Godot editor and (maybe) games

Created on 2 Oct 2016  Â·  16Comments  Â·  Source: godotengine/godot

It would be awesome if AppImages could be created for the Godot editor (for distribution of official or unofficial builds) and maybe exported games.

The goal of AppImages is to make portable Linux binaries easy. No dependencies need to be installed for users; think of it as macOS' .app, but for Linux, it's essentially an application bundle which can also provide basic system integration (such as menus and icons).

What needs to be done

  • Gather a list of all required libraries that are not linked statically to Godot. This can be figured out using ldd for example. Beware as some libraries should never be included in an AppImage.
  • Automate the creation of editor AppImages using SCons (or shell scripts). For this, a template AppDir must be created first, and put in the Godot Git repository (just like the macOS template). A script should be provided for copying system libraries to the AppDir.
  • Document the AppImage creation process.
  • Provide official AppImages as the recommended way of running Godot on Linux, for 64-bit and 32-bit. Some instructions should be provided as well (users still need to chmod +x them).

    Additional tasks

  • What should be done for games? I don't think it's feasible to export AppImages from a non-Linux system, but this needs to be confirmed. Perhaps we can provide a script that converts a Linux export to an AppImage.

    Resources

  • Documentation on creating AppImages

archived feature proposal linuxbsd editor

Most helpful comment

Creating an appimage from godot was quite easy using linuxdeploy and appimagetool. Pointing linuxdeploy at the godot binary automatically finds all the needed libs (except for the ones that cause issues such as libc, as determined by an official list from the appimage project). This generates an appimagedir that can be converted into an appimage using appimagetool.

We do this to provide a single file for our final game including some gdnative libraries etc (which do have to be copied in manually).

All 16 comments

See also #5241 which needs to be rebased before I can merge it.

I made a quick recipe
https://github.com/probonopd/AppImages/blob/master/recipes/meta/Godot.yml
The resulting AppImage is available for testing at
https://bintray.com/probono/AppImages/Godot/_latestVersion#files

It is expected that some more testing on different distributions and fine-tuning might be necessary. Ideally the upstream project would build the AppImage during the continuous build process.

First of all thank you for your report and sorry for the delay.

We released Godot 3.0 in January 2018 after 18 months of work, fixing many old issues either directly, or by obsoleting/replacing the features they were referring to.

We still have hundreds of issues whose relevance/reproducibility needs to be checked against the current stable version, and that's where you can help us.
Could you check if the issue that you described initially is still relevant/reproducible in Godot 3.0 or any newer version, and comment about it here?

For bug reports, please also make sure that the issue contains detailed steps to reproduce the bug and, if possible, a zipped project that can be used to reproduce it right away. This greatly speeds up debugging and bugfixing tasks for our contributors.

Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.

Thanks in advance.

Note: This message is being copy-pasted to many "stale" issues (90+ days without activity). It might happen that it is not meaningful for this specific issue or appears oblivious of the issue's context, if so please comment to notify the Bugsquad about it.

Whoever the bugsquad is, I think this is still relevant.

This issue is still relevant – I believe one of the primary goals would be to distribute an official Godot editor AppImage which could be downloaded from the Godot website (currently, it's just a statically-linked binary which is less guaranteed to work on freshly-installed systems).

@Calinou @akien-mga Sure this is a needed feature, I have tried to use snapcraft.io to install godot but it sounds broken. That snap is confined to use the jarsigner, which is provided from the openjdk that snap don't get access to.

Creating an appimage from godot was quite easy using linuxdeploy and appimagetool. Pointing linuxdeploy at the godot binary automatically finds all the needed libs (except for the ones that cause issues such as libc, as determined by an official list from the appimage project). This generates an appimagedir that can be converted into an appimage using appimagetool.

We do this to provide a single file for our final game including some gdnative libraries etc (which do have to be copied in manually).

@sdfgeoff Do you have any example deployment scripts you might be willing to share? I'm trying to package a game with native dependencies as an AppImage and am running into issues. In particular, if I export the game and manually create something approaching the structure of an appdir, including my GDNative dependencies, the game runs. If I create the appimage on my own distro (Fedora 30) and run it there, it runs. If I package it into an AppImage on my CI server using Debian 10, it doesn't run on my local Fedora 30 workstation. None of the errors are particularly explanative (I.e. no "Missing this or that shared library" that'd be easy to debug.) I suppose I could switch the CI server to use Fedora, but then I wonder if things would break on Debian/Ubuntu bases. Anyhow, trying to debug this here, but if you have it working in a cross-distro way with GDNative dependencies then I'd love to see that work, if possible.

Thanks.

@ndarilek AppImages should be built on the oldest distribution you wish to target, which is usually the oldest still-supported Ubuntu LTS (16.04 as of writing).

Due to glibc version incompatibilities, Linux binaries can only run on distributions as recent or newer than the distribution they were compiled on. The opposite isn't true – one can't run a recent binary on an old distribution.

I'm afraid I was doing it as part of my day-job, so I can't share anything here, but to me it sounds like you've got the packaging working and probably Calinou's suggestion is what you are after. There was nothing special I did (once I was informed that you have to put the gdnative libraries in the same folder as the binary).

The only other thing I can think of is that if you are using linuxdeploy to automatically detect/copy libraries, it will only do that for the executable you point it at. So if you have a GDNative library with a dependency, make sure you point linuxdeploy at that as well (or in some other way copy the libs into the appimage). Ideally running "ldd" on the libraries inside the appimage will point at other dll's inside the appimage rather than on the system.

Got it, I'll try ubuntu:16.04 as a base image. I guess what confused me
from your comment was the mention of both linuxdeploy and appimagetool.
I'm just using linuxdeploy ... -o appimage so I'm not sure if there's
a second step I may be missing. Essentially what I'm running is:

linuxdeploy --appdir appdir/ -d onslaught.desktop -e appdir/usr/bin/onslaught -i onslaught.png -l /lib64/libspeechd.so.2 -l appdir/usr/bin/addons/godot-tts/target/release/libgodot_tts.so -o appimage

So I wonder if maybe I'm missing another step in this process.

I'll see if I get the same errors with ubuntu:16.04, and if I do then
I'll post them here. There are lots of obtuse assertion failures that I
don't quite know how to debug.

Oh, I'm an idiot. Forgot to set up GIT_SUBMODULE_STRATEGY on GitLab,
so while one of my failures had to do with GDNative, the next had to do
with submodules not being available and I conflated the two.

FWIW, here's my GitLab CI setup for building appimages. Probably needs
work still, and has a download step for a component of my accessibility
addon, but this works for me and hopefully can help someone else. I also
version my .wav assets in my repo using LFS, though I only plan to ship
.oggs, so definitely don't just lift this without sanity-checking:

stages:
   - build

variables:
   GODOT_VERSION: 3.1.1

build:
   stage: build
   image: ubuntu:16.04
   variables:
     GIT_SUBMODULE_STRATEGY: recursive
     NO_STRIP: 1
   script:
   - apt-get update

   # Just install all build dependencies on the compilation page--too 
lazy to determine them one-by-one.

   - apt-get install -y build-essential scons pkg-config libx11-dev 
libxcursor-dev libxinerama-dev  libgl1-mesa-dev libglu-dev 
libasound2-dev libpulse-dev libfreetype6-dev libudev-dev libxi-dev 
libxrandr-dev yasm

   # libspeechd-dev is only needed for godot-tts.

   - apt-get install -y wget unzip libspeechd-dev
   - wget -q 
https://downloads.tuxfamily.org/godotengine/$GODOT_VERSION/Godot_v$GODOT_VERSION-stable_linux_headless.64.zip 
-O godot.zip
   - unzip godot.zip
   - mv Godot_v$GODOT_VERSION-stable_linux_headless.64 /usr/bin/godot
   - chmod +x /usr/bin/godot
   - wget -q 
https://downloads.tuxfamily.org/godotengine/$GODOT_VERSION/Godot_v$GODOT_VERSION-stable_export_templates.tpz 
-O templates.tpz
   - mkdir -p ~/.local/share/godot/templates
   - unzip templates.tpz -d ~/.local/share/godot/templates
   - mv ~/.local/share/godot/templates/templates 
~/.local/share/godot/templates/$GODOT_VERSION.stable
   - wget 
https://github.com/linuxdeploy/linuxdeploy/releases/download/continuous/linuxdeploy-x86_64.AppImage 
-O linuxdeploy.AppImage
   - chmod +x linuxdeploy.AppImage
   - wget 
"https://gitlab.com/lightsoutgames/godot-tts/-/jobs/artifacts/master/download?job=publish" 
-O addons/godot-tts.zip
   - unzip -d addons addons/godot-tts.zip

   # I version my original .wavs alongside their .oggs using LFS. Remove 
them since I only use .ogg assets.

   - find . -name '*.wav*' -delete
   - godot --export "Linux/X11" $CI_PROJECT_NAME
   - ./linuxdeploy.AppImage --appimage-extract
   - mkdir -p appdir/usr/bin
   - mv $CI_PROJECT_NAME $CI_PROJECT_NAME.pck appdir/usr/bin
   - cp addons/godot-tts/target/release/*.so appdir/usr/bin
   - ./squashfs-root/usr/bin/linuxdeploy --appdir appdir/ -d 
$CI_PROJECT_NAME.desktop -e appdir/usr/bin/$CI_PROJECT_NAME -i 
$CI_PROJECT_NAME.png -o appimage
   - rm linuxdeploy.AppImage
   - mkdir linux
   - cp *AppImage* linux
   artifacts:
     paths:
     - linux
     expire_in: 1 day

Just a tiny hint here; You know about formatting code with

    ```
    here goes the code
    ```

?

@probonopd That's what they used, but Markdown is not parsed when sent via email instead of the GitHub website (as done here).

Oh thanks. Yeah, I used ```, but didn't know that it didn't work over
email. Bummer, I typically use email to update issues.

Nowadays, I don't think Godot specifically needs to integrate AppImage somehow. Nearly everything is statically linked*, so as long as you use official Godot binaries or build them yourself on an old enough distribution, you should be fine. Therefore, I'll close this.

Maybe someone could write a documentation page for packaging a Godot project as an AppImage, but I don't see much point for a Godot-specific tutorial.

If the official binary doesn't suffice due to lack of automatic desktop integration, we now have a Flatpak for the editor as well as a Snap.

*: To build a compatible binary with recent GCC version on an old distribution, pass use_static_cpp=yes on the SCons command line.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ghost picture ghost  Â·  161Comments

diiiiiiiii picture diiiiiiiii  Â·  87Comments

karroffel picture karroffel  Â·  144Comments

NullNeska picture NullNeska  Â·  191Comments

reduz picture reduz  Â·  111Comments