Join us on our own very special Reddit on /r/Linuxers.

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
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
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: «7/13»
  Go to:

Lachu 17 Aug
When I was on University, we had trouble with Windows (Vista?), which dropped support for old Netware protocols, but it was
Windows, which have nearly entire market, so people must adapt.

Also, on one polish University device was created and they had problems write drivers for Windows. They wrote drivers for Linux without problems. Again.. This device do not be very popular due Windows had entire market and was stop existing. Simple - nobody bought it, so nobody produce it.
Lachu 17 Aug
And there exist games, like Heroes Of Might and Magic 3, which (as far as I known) do not work on Windows, so Valve remove it from shop. Also, on Vista was a lot of software, which do not work (Soldat, Neostrada Drivers, etc.). So do not create panic. Windows also do not have 100% backward compatibility. It have much greater, but telling Linux sucks is not very right.
Klaas 17 Aug
Quoting: Purple Library GuyUm, how many of these other thingies are we typically talking about existing at a time?
Run ldd on a binary and count the number of libraries that are referenced.
shorberg 17 Aug
View PC info
  • Supporter Plus
Quoting: DerpFoxBeing an admin too, I can relate to that. The only thing I can maybe "critic" is that here you are talking about Windows Server. So, I don't know if M reverting to the previous version is due to the company you worked for being huge or the problem being on Windows Server. On the server side, stability is an important thing.
Fair critique.

Quoting: DerpFoxThis year, an important software, of a company I used to work for, randomly ceased to work on Windows 10. Fortunately, they produced a patch rapidly. "Something" was changed in Windows 10, and they had to update sone of their code for it.
Aint that a blast. Gotta love the "something" part.

Quoting: DerpFoxBoth you and I have stories about zombie systems still maintained because something was broken in the Microsoft APIs. So, when I hear Windows API are more stable, I'm a bit sceptic. Particularly when I read people writing things like "I can still run software from Windows 3.x on Windows 10". Yes, they can run some, but the vast majority won't work any more. I think 3.x software started to break around Windows XP era. Even as gamers, how may of our 90s game, can we still start today on Windows 10/11? Not much, same is happening or has already happened with 00s games. And I think I have a couple 2010s games that are starting to act weird.
I'm not sure if that is because of the Win32 API or some other APIs but that was definitely already a case with XP as you noted. For the uninitiated (I envy you) this was when Windows stopped being built as a DOS application and moved to the NT-platform.

And to add to what DerpFox said, it has also been a big pain point for many gamers with the switch to Windows 10, as $SEARCH_ENGINE can tell.

Quoting: DerpFoxI'll now say monster names that will make some Sysadmins have cold sweat. AS400, Sun Solaris, OS/2, HP-UX, DOS.
Geez.. Language, man!

Since you love to throw around scary words like that on poor unsuspecting strangers; I'm gonna have to pay you back and ask if you have read the fine blog by Raymond Chen?


Last edited by shorberg on 17 August 2022 at 5:56 pm UTC
elmapul 17 Aug
QuoteWe are very interested in helping with any underlying resource constraints.
i understand that those projects need funding, but didnt that create an incentive to create problems so they can charge for an solution? not only on that project, but in others that listen that there is money to be made on breaking stuff...



QuoteMeanwhile, 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.

i said that a loong time ago, and people insisted that i was wrong.
hell even linus torvalds complained about this.

i wonder how the world would look like if we didnt had windows and as result wine, or how it will look like if windows die in the future, and if it didnt had consoles, retro gaming would be history...
F.Ultra 17 Aug
View PC info
  • Supporter
Quoting: Beamboom
Quoting: Eike
Quoting: Beamboom
Quoting: 1xokThis whole criticism from CodeWeavers developers should be taken with a pinch of salt...
... Why?

Because WINE is where their money comes from?
It's not like they're a neutral party in this question...

I see nothing wrong or biased in what they said.

New 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. There is a reason why Steam still have several versions of Proton since 3.7 available to choose from.
F.Ultra 17 Aug
View PC info
  • Supporter
Quoting: landeelglibc compatibility has been a pain for a while.
I have released 2 games on Steam with native Linux ports.
I'm always afraid of doing a dist-upgrade, because it's very likely the compiled binaries won't run on the previous distro version.
It's absurd, but targeting win32 is more stable.
There should be a way to have multiple working glibc versions.

There are, you can also in your code tell a new version of GLIBC that you want the function from the older version X since GLIBC uses versioned symbols and keep the old ones around since they started to do that. It's a very painful process though since one have to do this for every single symbol one want's to use.
Quoting: Klaas
Quoting: Purple Library GuyUm, how many of these other thingies are we typically talking about existing at a time?
Run ldd on a binary and count the number of libraries that are referenced.
No. I won't RTFM either.
In any case, would that tell me much about the total system usage?


Last edited by Purple Library Guy on 17 August 2022 at 6:11 pm UTC
F.Ultra 17 Aug
View PC info
  • Supporter
Quoting: minidou
Quoting: pgr
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 blame is not really about removing the deprecated feature. Blame is for the failure to restore it after discovering that users for the feature still exist and the removal broke stuff.

They did restore it because of the backlash, but they really shouldn't have, there's no reason for it. This isn't some obscure lib we're talking about but the GNU C library. If a handful of program gets broken it's on them, the function was marked deprecated almost two decades ago. An outstanding majority of program have no issue at all with the removal of this function, why should a niche but maybe high visibility user dictate the direction of glibc ?

Something not discussed here is that the removal of DT_HASH allows a save of about 1% or 16kB of space per Glibc shared object. This is an improvement. There clearly is a good reason for finally removing this deprecated function. But we shouldn't profit from this improvement because of some devs bad practice ?

Quoting: TheSHEEEP
Quoting: pgrThe blame is not really about removing the deprecated feature. Blame is for the failure to restore it after discovering that users for the feature still exist and the removal broke stuff.
Yes, a lot of developers (especially newer, younger ones that lack the experience) argue in favor of always using the very latest everything and always keeping everything updated.
I've seen that time and time again in several teams.

But that's not a position that can be maintained in reality.
You'd require armies just to maintain old stuff.

It's fine to remove a function if you can't see that anyone is using it. An understandable mistake.

This is off topic. The impacted softwares were initialised years after DT_HASH was marked deprecated. In the case of EAC lib, probably a good 15 years later. In every sector of the software industry this would be considered bad practice, but VG softwares get a pass for some reason.

Quoting: TheSHEEEPBut the moment you realize that there were indeed many still using it, it should clearly be restored (with a deprecation marker, but still).

They did that, almost two decades ago.

And it seems there isn't that many users impacted. I can count the EAC lib and some lib used in shovel night. Compared to the millions of programs using glibc.

I'm also wondering if this opens a hole in EAC. Aka since they only seems to check DT_HASH then I can craft a .so that have a nice DT_HASH for EAC to be happy about and then I create my real stuff in the DT_GNU_HASH section that is what the system really loads instead. Now I have never played around with low level linking like this so I don't know if this is possible, but it sure sounds like it.
iskaputt 17 Aug
On a slightly tangential note, this is a long but very interesting article about the sh*t-show that is ABI-compatibility in C(++)-land (reminder: the languages of choice for many games). There are a couple other similar articles on that blog (1, 2), also very enjoyable if you have the time to spare.
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.