Confused on Steam Play and Proton? Be sure to check out our guide.
We do often include affiliate links to earn us some pennies. See more here.

Recently it was noticed that users on more bleeding-edge Linux distributions that updated saw Easy Anti-Cheat no longer working on Linux, the culprit was glibc and now a Valve developer has spoken out about it.

Writing in a small thread on Twitter, Valve developer Pierre-Loup Griffais said:

Unfortunate that upstream glibc discussion on DT_HASH isn't coming out strongly in favor of prioritizing compatibility with pre-existing applications. Every such instance contributes to damaging the idea of desktop Linux as a viable target for third-party developers.

Our thoughts on the topic from this prior compatibility issue in BlueZ apply more than ever: https://github.com/bluez/bluez/commit/35a2c50437cca4d26ac6537ce3a964bb509c9b62#commitcomment-56028543
It is unfortunately yet another entry in a growing list over the years.

We understand that working with a focus on compatibility requires more resources and more engineering trade-offs, but strongly believe it is nonetheless the way to go. We are very interested in helping with any underlying resource constraints.

This prompted CodeWeavers (who work on Wine and with Valve on Proton) developer Arek Hiler to write a blog post titled "Win32 Is The Only Stable ABI on Linux" and their ending statement is something people should think on:

I think this whole situation shows why creating native games for Linux is challenging. It’s hard to blame developers for targeting Windows and relying on Wine + friends. It’s just much more stable and much less likely to break and stay broken.

Hiler certainly isn't the only one to think like that, with another CodeWeavers developer Andrew Eikum mentioning on Hacker News some time ago:

As a long-time Linux dev (see my profile), I have also found this to be true. Linux userland APIs are unstable and change all the time. Some transitions that come to mind that have affected me personally: ALSA->pulse; libudev->libudev2->systemd; gstreamer 0.10->1.0. All of those changes required modifications to my software, and the backwards-compat tools that are provided are buggy and insufficient. Meanwhile, you can still write and run winmm[1] applications on Windows 10, and they will work in almost all cases. It's simply the case that the win32 API is more stable than Linux userland APIs, so it's entirely plausible that games will run better in Wine, which shares that stable ABI, than they will on Linux, especially as time goes on and Linux userland shifts yet again.

[1] winmm dates to the Windows 3.x days!

Situations like this can be pretty messy and this is not a case of open source versus secret closed source anti-cheat stuff either, since the glibc issue affected a Native Linux game (Shovel Knight) and Linux software libstrangle. No doubt there are other things yet to be discovered that were broken by the change.

It is of course also a case that Linux distributions need to ensure they do quality assurance testing, especially for gaming which can end up showing up issues quite easily and that bleeding-edge distributions can and clearly do end up breaking things by pulling new software in so quickly.

Article taken from GamingOnLinux.com.
43 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
123 comments
Page: «2/13»
  Go to:

damarrin 17 Aug
View PC info
  • Supporter Plus
Quoting: TermyI tend to agree with the criticism about unstable APIs for many cases - but in this case, i really blame Epic for using a function deprecated for almost two decades in a recent piece of software.

Well, the function wasn't marked as deprecated as far as I can tell, it was just removed in a minor update without warning. The Epic engineer probably didn't know about it, they just used a function that was there and had the rug suddenly pulled out from under them.

And since Epic doesn't care about Linux because no users and it was Valve who probably pressured/paid them to support us, this is basically Linux people shooting Linux in the foot... almost as if they didn't want more people using it. Imagine that.
melkemind 17 Aug
Quoting: minidouAlso, didn't Valve add the steam runtimes to counter exactly this kind of issue ? If some software need ancient dependencies, don't use system ones, use a set of libs managed by steam.

There's a reason Windows is a huge bloated mess, and it's because they maintain compatibility with ancient software that a lot of enterprise clients still use. I don't know that this is really a case of one way being right and the other being wrong. It's just a different approach. The very thing that makes Linux so much better on portable devices like the Steam Deck also comes with the drawback of not having every ancient library crammed into it in order to keep compatibility with IBM XT computers from 1983. In that regard, Wine is a great alternative.
Sundragon 17 Aug
Either way I do hope this leads to a solution sooner rather than later. Can the Steam runtime not use its own glibc? I have definitely heard that particular library has been a problem with updates.

Quoting: damarrinAnd since Epic doesn't care about Linux because no users and it was Valve who probably pressured/paid them to support us, this is basically Linux people shooting Linux in the foot... almost as if they didn't want more people using it. Imagine that.
I mean if you want to point fingers, it's not so much "linux people" as it is glibc/GNU developers. Definitely heard cooperation there can be difficult.
Zlopez 17 Aug
  • Supporter Plus
Quoting: minidouI fail to see how glibc devs could be blamed for removing a function deprecated for 17 years (though I can agree a major version bump should have been called for). Do videogame devs need that much nursing ? EAC linux lib is a recent piece of software, how many deprecated dependencies do they use ?

The issue here is that there are plenty of games that are just abandonware at this time and you need emulator in most of the cases to get them running. I personally saw old Linux port that are still working in Proton, but are not playable on the current Linux machine (I'm actually really glad that the Valve came up with something like Steam Linux Runtime, because the Linux port targeting this container environment will always work in it, even when the OS under it will change all the time).

So the backwards compatibility is something that is called for. Even Linus Torvalds said: "Never break user space!" (This is why the Linux kernel is so stable and works on almost any machine.) Even if the feature has a bug, leave it there, just mention it in the documentation. Don't remove or change any call in your API or ABI, you will break things, always.
Older native Linux games could be very difficult to launch today on new distro. Most of the time, to play old games on Linux, I use Windows version + Wine. And Windows version have more updates available or mods choice.
orzo 17 Aug
  • Supporter
Quoting: ZlopezEven Linus Torvalds said: "Never break user space!"
Here is his full speech (+/- 6 minutes), including rant on glibc. It's eight years old now.

https://youtu.be/5PmHRSeA2c8?t=333
Xpander 17 Aug
Quoting: TermyI tend to agree with the criticism about unstable APIs for many cases - but in this case, i really blame Epic for using a function deprecated for almost two decades in a recent piece of software.

Blame libstrangle and Shovel Knights devs also?
Still the issue is that it wasn't really advertised that its gonna get removed and is replaced with other method. It was pretty much hidden in some blogspots. Also what if you have some software that is way older. There needs to be a backwards compatibility.

Epic or EAC devs can fix this surely at some point, but what about the software that never gets maintained anymore?
1xok 17 Aug
Win32 Is NOT The Only Stable ABI on Linux. The kernel ABI itself is also stable. Not least thanks to Linus Torvalds. There is a now legendary email from Linus about this (caution, harsh tone):

https://lkml.org/lkml/2012/12/23/75

Unfortunately, the rule "WE DO NOT BREAK USERSPACE!" is often not applied in userspace itself, even when it comes to system libraries. I always find it most tiresome when people insist on their changes even though countless regressions have already occurred.
Beamboom 17 Aug
Quoting: 1xokWin32 Is NOT The Only Stable ABI on Linux. The kernel ABI itself is also stable.
They clearly and consequently state userspace.

Quoting: tonyrhThis whole criticism from CodeWeavers developers should be taken with a pinch of salt...
... Why?


Last edited by Beamboom on 17 August 2022 at 10:03 am UTC
1xok 17 Aug
Quoting: orzo
Quoting: ZlopezEven Linus Torvalds said: "Never break user space!"
Here is his full speech (+/- 6 minutes), including rant on glibc. It's eight years old now.

https://youtu.be/5PmHRSeA2c8?t=333

At 10:50, he mentions Valve directly:

https://youtu.be/5PmHRSeA2c8?t=650

It's so sad that this doesn't change.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.