[Feature Request, Question] Automated Linux builds/releases

[kevin-wijnen]

Context

I've noticed that in the releases, no Linux binaries are delivered along with the iOS (.deb, .ipa), macOS (Cocoa) and Windows (SDL) builds. The current CI/CD build workflow (sanity.yml) does account for Linux builds, built with both gcc and clang under Ubuntu (20.04, latest).

Is there any reason no Linux build(s) are attached with the manual releases?

Proposal

• Add a "See Releases for pre-compiled binaries." link in the README.md, redirecting to the GitHub releases page.
• Add any type (or all) of Linux build(s) to future releases, in a similar fashion to the iOS, macOS and Windows release; either from last manual compilation or taking the latest canary build.
• Add (if possible) links to the latest canary builds from all versions that are created through the workflow (macOS, Ubuntu-20.04, Ubuntu-latest) in the README.md for quick downloads.

  A suggestion would be to utilise nightly to always have up-to-date links to the latest workflow builds. Another possibility would be to create nightly releases directly via GitHub Actions that can be easily downloaded.

• Once Flatpak support is considered "official"/"complete" (as per Flathub #491 and Added AppStream metadata #492) - add its link (and possibly a Flathub badge) to the README.md.

---

If all or most of the proposals are considered worthy of inclusion, I would not mind creating a Pull Request to incorporate said changes to the README.md to easily navigate users towards the releases.

[LIJI32]

The main reason Linux binaries are not provided is that generally speaking, Linux binaries are not portable – A binary built on Ubuntu 23.04 won't work on an older release, and it will probably not work on most other distros. Portability issues can be mitigated by statically linking everything, but this has costs:

• The executable size becomes much larger, as it will include every direct and indirect dependency of SDL
• Statically linking GUI libraries and using them on a system that uses newer or older versions of the same libraries can cause inconsistencies and bugs
• By not sharing libc with the rest of the system, cache utilization is degraded, that can have notable negative effects on SameBoy's performance

I'm not very familiar with Flatpak. It seems like it probably fixes or mostly mitigates issue 2, but adds more overhead that enhance the impacts of issues 1 and 3.

In the bottom line, the best way to experience SameBoy on Linux is to build it yourself, or to use a distro that has it in its repos (e.g. Arch, with AUR), and I'd rather not offer something less than ideal as a default. It is unfortunate, but fragmentation and poor design choices (cough glibc cough) made portable binary distribution on Linux distros extremely hard (which is why Flatpak has to exist to begin with). Ideally, I'd want an official Linux binary release to be a dynamically linked executable that works across a wide range of distros, as long as some reasonable requirements are met (e.g. a minimum version of SDL2 is installed).

As for canary builds – SameBoy's untagged releases are not meant for end-users. Firstly, they can, and often do, break save state compatibility. They often fail to read save states of tagged versions, and often create save states that can't be read by any other version. Secondly, increased fragmentation in SameBoy versions make bug reports much harder to handle – the libretro builds used to be released from arbitrary commits for example, which made fixing bugs reports from libretro users extremely hard (and often they ended "false positive" reports that were already fixed in master and never existed in a tagged release).

I hope this answers all your questions.

[kevin-wijnen]

Thanks for providing the very detailed insight and well-thought opinions on providing Linux binaries. To me, it is clear why providing Linux binaries would be an issue for this project specifically.

---

Regardless, I would like to add the following to the discussion. Personally, I do think issue 1 should not be considered an issue in the modern days of computing where storage is now in the GBs and TBs for system drives. While I do not know what the exact file size increase would be when fully including the SDL dependencies in the executable, it seems to be a trivial concern to worry about. This is more valid of a concern for any ARM32/ARM64 builds for smaller computing devices like a Raspberry Pi, but even those often use either a big enough eMMC or microSD card to accomodate for a larger executable size.

Are there any cases of issue 2 being a realistic scenario? From the experience I have using either Flatpak or AppImage (with the libraries embedded within), embedded libraries despite the system having either newer or older ones installed are not an issue as the binary would use the included libraries over that of the system. Not to mention, one can overwrite library versions on Linux by using simple commands (such as LD_PRELOAD). Not to mention, there are serious downsides to using a dynamically linked approach (most notably: incompatibility for immutable OSes such as Fedora Silverlight and SteamOS due to missing/outdated libraries out of the user's control, and incompatibility when using newer versions of libraries on any system). I've personally seen incompatibilty issues with pre-compiled DOSBOX binaries for Linux on SteamOS, forcing end users to use a Flatpak distributed form for it. Either distributing binaries via a system like Flatpak, or statically linking them in either distro-specific packages (.deb for Debian-based systems for example) or as an AppImage with statically linked libraries (distro neutral packages, similar to Windows .exe in end-user function but more like macOS' .dmg in technical implementation) could be an outcome to mitigate the library availability issue as much as possible.

However, performance is a valid concern that is definitely interesting to keep in mind for SameBoy. I would not have an answer to the actual performance impact of using shared libraries.

---

Personally, I would suggest considering AppImages as a form of distribution of dynamically linked binaries that are distro independent. appimagetool - should make dynamically linked binaries possible - if I'm not mistaken ("But using shared libraries..." point's answer). Although it is generally discouraged due to its impact of compatibility.

Once again however, thanks for answering the questions. My main motivation was to potentially make it possible to start distributing Linux binaries officially to support systems that are locked down with libraries such as the Steam Deck. While using the unofficial Flatpak version from Flathub seemed fine, I do have a preference to AppImages or simply compiled binaries to run directly.

I'll keep the issue open (for now) as there seems to be still a wish for a proper Linux binary release which doesn't statically link all libraries. If I happen to find a solution that matches that requirement, or otherwise find new information on it. I might personally try to get an AppImage pipeline going in a fork of the project, to see if that would work on at least SteamOS without statically linking libraries with it.

[electricbrass]

One thing to note about AppImages is that it is possible for them to use the system libc, so issue 3 can be avoided.