Consider package official executable directly?

[j20001970]

I wonder if it is desirable to package Godot editor binary from official releases as flatpak, since there are some differences between official and flatpak version in terms of build configuration (such as several modules are system provided). These differences might lead to some issues that are not present in official version.

Some context: I'm developing a GDExtension plugin for Godot, and recently exploring a way to build the source from flatpak environment for libraries distribution. The current flatpak version of the editor will crash immediately when loading a project with the plugin, but running the official editor from flatpak runtime will load the libraries as expected. After some trial-error, I found that making freetype, libpng, zlib, graphite, harfbuzz built-in could solve the problem, but at this point it might be simpler by just bundling official editor into flatpak.

[Calinou]

• Related to https://github.com/flathub/org.godotengine.godot.BaseApp/issues/4.

Shipping precompiled binaries is discouraged for open source applications, as one of Flathub's goals is ensure the source code works in the same way as officially-provided binaries. F-Droid takes a similar approach with its store.

I'm surprised GDExtensions crash due to libraries not being built-in though, as the GDExtension API doesn't directly expose these libraries.

Edit: bruvzg said about this:

I suspect it might be caused by GDExtension using incompatible version of ICU (probably by proxy from other library), built-in version is built with U_LIB_SUFFIX_C_NAME=_godot flag to avoid conflicts (since .NET runtime include its own version and that can cause issues).

[j20001970]

So compiling Godot from source is preferred method for flatpak distribution.

Regarding GDExtension crash, there is not much of information when editor crashed, only with a message like this:

handle_crash: Program crashed with signal 11 Engine version: Godot Engine v4.2.1.stable.flathub (b09f793f564a6c95dc76acc654b390e68441bd01) Dumping the backtrace. Please include this when reporting the bug to the project developer. [1] /usr/lib/x86_64-linux-gnu/libc.so.6(+0x3ee80) [0x7f9b7ff1be80] (??:0) -- END OF BACKTRACE --

I also tried removing some code dependencies that involve OpenCV (also built from flatpak environment) and self-registration from the library, then it will load without issue. It is just a speculation but I doubt that linking OpenCV libraries would be the reason of crash, it is more likely the code of the library (or other dependencies that compiled into it) trigger the crash when some of Godot's modules are system provided instead of built-in. I have no idea how to further debug this, is there any tips on troubleshooting such issue?

[j20001970]

Edit: bruvzg said about this:

I suspect it might be caused by GDExtension using incompatible version of ICU (probably by proxy from other library), built-in version is built with U_LIB_SUFFIX_C_NAME=_godot flag to avoid conflicts (since .NET runtime include its own version and that can cause issues).

Thanks for the pointer, is there anything we can do to avoid conflicts from GDExtension libraries side? I tried to set my own U_LIB_SUFFIX_C_NAME flag when building the library, but it still lead to the same crash message.

[j20001970]

I think this issue is better reporting to Godot upstream, since the problem isn't flatpak-specific, sorry for bothering.

[RokeJulianLockhart]

https://github.com/flathub/org.godotengine.Godot/issues/153#issuecomment-2087955735

@j20001970, it is Flatpak-specific. It's even Flathub-specific. Anyone can host a Flatpak repository and configure it however they want.