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.
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
Page: «8/13»
  Go to:

drjoms 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.
Apple products also suck balls. Criticism of Linux is still valid.
With that said, what prevents all games from shipping old system libraries?
Klaas 17 Aug
Quoting: Purple Library GuyIn any case, would that tell me much about the total system usage?
Only if you do that for everything that you use (ignoring duplicates). It's very hard to estimate as it hugely varies between programs and obviously the number of programs that you use simultaneously.

The upper bound is the number of unique files in /usr/lib, although that should overshoot the real number by a huge amount.
Distro maintainers should really start using something like OpenQA more, especially rolling and bleeding edge distros, as it should be able to detect such issues long before something gets in the Repos.

Thank you Tumbleweed for using it!

(Fingers crossed they actually test this DT_HASH thing in glibc with various software and hold it back until a fix is available ._.)

Last edited by Vortex_Acherontic on 17 August 2022 at 6:53 pm UTC
slaapliedje 17 Aug
View PC info
  • Supporter Plus
Note: I did not ralead through the 70+ comments, but...
QuoteSituations 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.

Not entirely accurate as if the games themselves were also open source, they can be modified and compiled with fixes to deprecated stuff and use new features. This is why Stallman has always said that games would be better to use open source engines, and could have proprietary data.

I will have to read up on the rest of the thoughts, and why some function was removed / changed in libc.

Also, while Wine is fantastic at getting windows of all versions to work under Linux, Windows itself may still 'support' some old stuff, but that doesn't mean some of the implementations still work in Windows 10/11.

Look at all the SafeDisk stuff that will no longer work without dubious cracks.
MayeulC 17 Aug
LSB was a good idea. We need more automated testing to catch that kind of bugs. FULLY cover important APIs.

If an application requires qn older "base" or an older libraries, shims should be provided, and that should be exercised with tests.

Of course, that requires a substantial ammount of effort :/
This is why we in the "enterprise" world of servers prefer distros such as RHEL which backport security and bugfix patches but retain compatibility with existing software for a number of years by locking software versions instead of a rolling release distro like Arch with constant new versions. Yet we were always judged for running "old software" by the general non-admin linux crowd 😂

Maybe now they can understand why we do it that way. 😂

With that said, we shouldn't stop developing or pushing ahead in our FOSS software by holding back development just to keep some proprietary spyware like EAC working that doesn't play nice in the first place.
Klaas 17 Aug
Backporting security fixes can lead to a lot of trouble if something is missed. Remember the Debian OpenSSL bug a few years ago?
I was speaking more along the lines of RHEL or SLES.

For example, RH very much keep up with latest CVEs and catalogue them for their customers and detail whether it's fixed, unaffected or vulnerable:


With that said having the latest versions of software doesn't make you immune from security issues either, nor less likely.

It can also go the other way, a security issue can occur only in a new version of software but not affect older versions, there have been several security issues over the years that simply didn't affect RHEL because the security bug was only present in newer versions of software.

Also, a security issue can go unnoticed for years in software, even eith latest versions. Then there's developers who deem certain things "not a priority" who don't patch a security bug they know exists (this affects proprietary software like windows mostly)

Don't assume that just because patches are backported that the software is more vulnerable as a result. RH has a lot of professional employed security experts keeping tabs on this.

Edit: Typos.. I hate typing on smartphones...

Last edited by BlackBloodRum on 17 August 2022 at 9:19 pm UTC
Beamboom 17 Aug
Quoting: F.UltraNew releases of WINE/Proton breaks games that worked with the older version from time to time so yes they are wrong in that WIN32 is the only stable ABI on Linux since it clearly isn't stable.

It's not a either/or, binary reality discussed here. It's not a question if this or that ever breaks at all, ever.
Klaas 17 Aug
Yes, obviously. But my point was that the supposedly stable things have large caveats as well and it is really not related to the current issue at all to constantly state that rolling release distribution break everything constantly. This is not an issue of rolling vs frozen distribution.

I don't think things like this breakage can be tested automatically since you'd have to create so many obscure test cases that the effort would make it infeasible.
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.