Comments (2)
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.
from sameboy.
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.
from sameboy.
Related Issues (20)
- Cheats Not Working
- Could not open ROM: Permission denied
- accuracy tests HOT 2
- Keitai Denjuu Telefang - Power Version (Japan) (GB Compatible).gbc missing speech from title screen
- Donkey Kong ('94) - Pauline's cry is silent when using SGB emulation
- GB Classic: F1 Race - flickering line midscreen
- macOS: Do not hide panels when app focus is lost
- ROM files cannot be imported HOT 2
- Iphone HOT 2
- Switch Pro Controller iOS recognized, but unable to use HOT 2
- iOS: Gameboy Advance Games don’t get recognised HOT 3
- Add custom palette for iOS
- Cloud sync iOS HOT 2
- Polished Crystal iOS (Fixed) HOT 1
- Hex digits invisible in SameBoy Cocoa v0.16.5 HOT 1
- Pocket Family (HuC-3) doesn’t do sound test HOT 3
- [Feature Request] Toggle all cameras on iOS port
- Instructions for testing the gameboy camera integration on real iOS devices HOT 5
- Turbo Speed does not stay HOT 4
- Associate ROM files with SameBoy on Windows HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sameboy.