Description
| Previous ID | SR-1364 |
| Radar | None |
| Original Reporter | ewmailing (JIRA User) |
| Type | Task |
Additional Detail from JIRA
| Votes | 0 |
| Component/s | |
| Labels | Task, Linux, SteamOS |
| Assignee | None |
| Priority | Medium |
md5: c0767ecd5e2d09923a857befc43db0c0
Issue Description:
I would like to propose the idea of doing automated builds for SteamOS/Steam-Runtime (Linux desktop distro).
For those who don’t know, Valve is the largest app store for games. They have supported Linux for awhile now. Because of Linux binary compatibility hell, they have developed an environment called Steam-Runtime which creates a stable/predictable binary runtime environment which Steam/Linux games get launched in. This allows developers to ship a single Linux binary that will work on all the Linux distros that you can get Steam for. And Valve is promising to maintain ABI compatibility unlike other Linux distros.
Valve raised the ante recently by creating SteamOS, an entire Linux distro dedicated for games. It uses this same Steam-Runtime.
SteamOS is a fork of Debian, but the original ABI was based on Ubuntu 12.04. So if you built a Linux binary under Ubuntu 12.04 and were careful about dependencies, it would work everywhere Steam-Runtime worked.
Steam-Runtime updated their compilers to be slightly more modern (gcc 4.8 and clang 3.6), which breaks Ubuntu 12.04 compatibility, but this reveals another thing about Linux ABI compatibility. Assuming you are careful about your library dependencies, generally Linux/glibc is forward compatible. So you can build on Ubuntu 12.04 and it still works in Steam Runtime, but the reverse is not true.
But the reason this is interesting is because Steam-Runtime itself is promises stability and uses an older glibc ABI than most modern distros. This means there is a high chance that building a binary under Steam-Runtime will allow it to work on most other Linux distros without any funny stuff. (You don’t have to bring up the Steam-Runtime runtime environment unless you have library dependencies that aren’t available in your normal environment. Swift has pretty minimal library dependencies as far as I can tell.)
So I’m proposing that Swift do official automated builds for SteamOS/Steam-Runtime because these binaries have a good chance of running on other modern Linux distros in the absence of a dedicated build for each distro.
One additional nice thing is that you can download and create a Steam-Runtime environment for almost all Linux distros. It lives in its own sandbox via schroot. So we can piggyback off an existing Ubuntu install without affecting it if this is an issue.
One important caveat is that this is connected to me bug about static linking ICU. SteamOS/Steam-Runtime do not officially provide ICU as a library (but both OS’s use it internally). But this further ensures that the Swift built in Steam-Runtime will work on other Linux distros since every distro is going to have a different version of it anyway.
Related to bugs:
https://bugs.swift.org/browse/SR-1358
https://bugs.swift.org/browse/SR-1359
(and other ones I filed about ICU which are labeled)