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: 1/13»
  Go to:

Jpxe 17 Aug
Isn't Flatpak the solution to this? Then you can just target the runtime environment and it will always stay the same as I understand it.

Also isn't this the the same on iOS, Android and macOS. Aren't they always changing things and "breaking" backwards compatibility? They still seem to be a very viable target for third-party developers.
Eike 17 Aug
View PC info
  • Supporter Plus
Quoting: Pierre-Loup GriffaisWe are very interested in helping with any underlying resource constraints.

Yes please!


Last edited by Eike on 17 August 2022 at 7:52 am UTC
Spyker 17 Aug
Hopefully this issue will catch the right people in the community so we can bring with a solution in favour of compatibility.
I don't want people to give up on native Linux support because of this.
tonyrh 17 Aug
Quoting: JpxeAlso isn't this the the same on iOS, Android and macOS. Aren't they always changing things and "breaking" backwards compatibility? They still seem to be a very viable target for third-party developers.

Yeah... the only difference is those OSes have users, so there is actual interest in maintaining and fixing stuff.

This whole criticism from CodeWeavers developers should be taken with a pinch of salt...
Xpander 17 Aug
Quoting: JpxeIsn't Flatpak the solution to this? Then you can just target the runtime environment and it will always stay the same as I understand it.

No its not a solution. It has its own issues with different GPU driver versions.
And also holding back updates or reverting breakages will pile up sooner or later and will be a huge maintenance burden.


Last edited by Xpander on 17 August 2022 at 8:00 am UTC
minidou 17 Aug
I 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 ?
minidou 17 Aug
Also, 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.
Quoting: JpxeIsn't Flatpak the solution to this? Then you can just target the runtime environment and it will always stay the same as I understand it.

Somewhat, containerization in my opinion is suited for user applications where security is not paramount. In a sense referenced in the article above -- win32 and wine fit that bill.

Quoting: JpxeAlso isn't this the the same on iOS, Android and macOS. Aren't they always changing things and "breaking" backwards compatibility?

Similar I guess, I'm not in the thick of it, but I imagine their breakage aims to "fail gracefully", thus depreciation messages, from reading the link it sounded like the valve dev was suggesting a "version handshake" -- I totally agree if you are going to change things you should have API versions that make it clear which functions are available and for them to behave a in a predictable way thus announcing behavior changes in handshake.

Quoting: JpxeThey still seem to be a very viable target for third-party developers.

For sure, though when you are a dev and you wake up and go get your morning coffee -- the last thing you want to see is a bomb go off that fucks up your workflow, progress schedule and day, the last thing you want is to put in overtime to catchup with already rigorous deadlines.

Technically I thought Steam Linux Runtime was supposed to take care of these kinds of cases, but I guess this was something they caught?

I was once told that every system has its drawbacks or flaws and no system is perfect (in this case I apply it to the Linux Platform) -- I think realizing that is important and a step toward practicality -- and I think this post highlights some room for improvement fortifying the stack.

Also I just cut everyone a bill of slack considering the times we're living in, only natural some of us are going to get a little bit burnt & crispy, techthings can be very trying at times, props to everyone doing their best to mitigate these hiccups as we go foreward.


Last edited by ElectricPrism on 17 August 2022 at 8:07 am UTC
Termy 17 Aug
I 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.
damarrin 17 Aug
View PC info
  • Supporter Plus
Good job telling people "my way or the highway" and watching in bemused surprise as they choose the highway. And we wonder why we have no users.

As has been mentioned above, this is the dominant position in the mobile space, with Apple recently starting to remove "unmaintained apps" from their app store. They also do this on the desktop, to a lesser degree. If anyone ever wondered why everything is subscription-based there, this is the answer. Software requires constant work, you can't just publish something and expect it to work months, much less years down the line.

I put up with this on my phone because privacy (though I've given up on paying for anything), but not on the desktop. Here, the standard Microsoft has created is the correct one and Linux people should be following them and not the Apple way. Unupdated software should continue working for decades. This is how you build trust and reliability.
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.