-
-
Notifications
You must be signed in to change notification settings - Fork 19k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Building AppImages for Godot editor and (maybe) games #6681
Comments
See also #5241 which needs to be rebased before I can merge it. |
I made a quick recipe 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. 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
? |
@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 |
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
ldd
for example. Beware as some libraries should never be included in an AppImage.chmod +x
them).Additional tasks
Resources
The text was updated successfully, but these errors were encountered: