6

If you build an executable that works on a current version of Windows, that executable will probably work for many years on newer versions of Windows. Microsoft works very hard to ensure this.

With Linux, there's an expectation that you'll have the source code to the software you're using, and therefore breaking binary compatibility is OK as long as you maintain source compatibility. This leads to distros phasing out old library versions and periodically breaking things that used to work.

For someone using Linux as a gaming platform, this is a problem, because games tend to be distributed only in binary form. It makes Linux ports look bad when they break, but I have a feeling it would be more productive to try to solve this problem generally, rather than expect everyone to update their ports.

Are there any distributions that try to preserve binary compatibility, not necessarily by keeping all old versions around but at least keeping old sonames, such that a binary that works with release n should also work with release n+1?

The closest thing I can find is Valve's "Steam Runtime", which is a binary compatibility layer only available to programs distributed through Steam.

Improve this question
4
  • 1
    If the binary is statically linked, it doesn't need to care.
    – jordanm
    Commented Jun 16, 2014 at 15:45
  • 1
    I would guess a hidden issue here is that there is little to no motivation for game distributors to put any effort into the linux versions -- as jordanm implies, it is easy enough to just ship a static version if your thing is sensitive. But while games are a billion dollar industry, I'd be surprised to hear that games on linux generate much into 6 figures. On the flip side, there's essentially zero motivation for mostly volunteer open source devs to compensate for this so that the gaming industry can make more money.
    – goldilocks
    Commented Jun 16, 2014 at 16:33
  • Statically linked binaries are not a perfect solution, and would actually break things in some circumstances. Any game that statically linked ALSA libraries before Pulseaudio existed would fail to work on a Pulse system, because it would lack the ALSA plugins that work through Pulse. Statically linking to libGL is also not an option.
    – Esme Povirk
    Commented Jun 17, 2014 at 23:24
  • As peterph mentioned, statically linking also leads to security problems, as your libraries will never be updated.
    – Esme Povirk
    Commented Jun 17, 2014 at 23:36

1 Answer 1

Reset to default
6

Basically this boils down to: you can't keep binary compatibility and introduce new features, since these things go directly against each other in most aspects. If you introduce major new features you in the end have to change the ABI (usually shortly after the changes in the API). Now, you can have versioned symbols (like for example Glibc has), but this makes the libraries grow in size (and may also incur some performance penalty while loading a binary into memory) and developers certainly don't want to keep it in general libraries (the legacy code contains bugs that nobody is interested in fixing).

The usual way to go around this on distribution side is twofold:

  1. do not change versions - this is typical for Enterprise-grade distributions like (in alphabetical order) RedHat and SUSE, as well as for some others (Debian, Slackware, Ubunty LTS and probably their clones).

  2. allow installation of various versions of a library at the same time.

On the application distributor this is handled in the same way as on windows: stuff everything needed into the distribution package. Yes, this is the way it is often done on Windows - this is also one of the reasons for typical Windows system usually having several times higher disk space requirements than Linux with the same functionality - the applications are simply sharing only very little among themselves and have their own copies somewhere. You can think of it as of every GTK/Qt application coming with its own GTK/Qt stack. It can have some advantages but disadvantages are also plentiful. For example from security point of view it is a nightmare in TechnicolorTM. If the binaries are statically linked, it's even in FullHD.

Improve this answer
2
  • Allowing installation of various versions, or even compatibility libraries that translate from the old ABI to the new one (so you don't have to keep applying security fixes to old libraries forever), seems like a viable option to me. But it requires packagers that really care about this.
    – Esme Povirk
    Commented Jun 17, 2014 at 23:36
  • Wrappers are not always an option - if API changes for example by eliminating or adding a new parameter, what is a wrapper supposed to do? Application developers need to care about their software as well, and not just use whatever the get their hands on and then forget about it completely. Unfortunately, even if developers would want to do that, they are often not able to do that for financial reasons. How much these reasons are real and how much it only is a wrong ideas in the heads of the managers is a different topic. Very interesting one, but out of scope here. :)
    – peterph
    Commented Jun 18, 2014 at 10:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .