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

Quoting: KlaasYes, 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.

It's all on usage case. For a server, stable is better.

Both options have caveats and issues to deal with.

My point was that people (such as yourself) often believed that enterprise level distros were pointless even for servers (You have no idea how many times I've had this exact discussion over the years) and proceed to attack enterprise grade distros, citing false security concerns and caveats and would suggest that running arch on a server was a better option.

Meanwhile in the enterprise world we always cited compatibility as a primary concern which this EAC issue highlights.

So my point was merely it would help you understand why we use such software in a stable environment that allows us to keep our systems running without breaking software.

That rolling isn't always a better option, software changes and it's the nature of the beast, it's how you handle those changes that matters.

In my case I use both, I use rolling release for my desktop and stable for servers. Best of both worlds 🫠


Last edited by BlackBloodRum on 17 August 2022 at 9:30 pm UTC
CyborgZeta 17 Aug
I am not a software developer or a progammer; I am just a regular computer user. So please do not get angry at me for asking this, as I probably don't know what I'm talking about.

But wouldn't running games, and programs/applications in general, inside containers fix this kind of issue? Isn't that one of the goals of Flatpak?


Last edited by CyborgZeta on 17 August 2022 at 10:12 pm UTC
shorberg 17 Aug
View PC info
  • Supporter Plus
I wasn't going to comment on this because it is way off-topic, but having thought about it for a while I decided to do so anyway, in the interest of public education on neural diversity. Liam or moderators may remove this if they think it inappropriate.

Quoting: dibzYeah, one of the best and worst things about Linux is the vocal community. And let's be honest, the people that flock tend to have very strong personalities -- borderline autistic at times.
Autistic is not the word you are looking for here. It is a common and widespread misconception, but it really isn't what you are looking for to describe the individuals you are hinting at. Autistics are often asocial, generally not antisocial. Typically, if an autistic person learns they have said or done something that have hurt someone, they will feel intense remorse.

A "borderline autistic" person is a perfectly average person, you likely won't even notice anything different except perhaps slightly increased anxiety compared to baseline human their age. At most you might describe them as someone who likes to stay home and read a book on a Saturday every now and then.

They are not people who will try to rally the masses, they will probably just stand at the sideline wishing they could contribute more. There are exceptions though, a certain fellow countrywoman is a strong personality who does quite a bit to hold people accountable for the climate.

Quoting wikipedia,
QuoteThe autism spectrum is a range of neurodevelopmental conditions generally characterized by difficulties in social interactions and communication, repetitive behaviours, intense interests, and unusual responses to sensory stimuli.
The difficulty in social interaction and communication refers to discomfort and avoidance and reduced body language. But many autistics won't put themselves in most social situations to begin with, either because of a lack of interest in social activities or because it confuses them. Even mailing-lists, or forum posting is something that scares many.

Source: I've done a lot of reading on autism, I have talked to a lot of professionals, I have friends who are autistic and I am autistic myself. I am however far from an expert, and open to learn more.

PS. What I have described as autistics above is not a set of all people with autism spectrum disorder, it is a generalised set of the ones who are high-functioning enough that you are likely to have been in contact with them in something as complex as technical online discussions.
Quoting: CyborgZetaI am not a software developer or a progammer; I am just a regular computer user. So please do not get angry at me for asking this, as I probably don't know what I'm talking about.

But wouldn't running games, and programs/applications in general, inside containers fix this kind of issue? Isn't that one of the goals of Flatpak?

Yes and no.

It's not so much a technical limitation at this point, but rather a legal one.

It could be done in a number of ways but EAC, being proprietary, cannot bundle a glibc binary into their closed source product for redistribution in another closed source product (the game) for legal reasons since it breaks to LGPL terms.

In addition the glibc devs heavily advise to always dynamically link to the OS's glibc for best overall compatibility and security.

(EAC did correctly here by dynamically linking)

Usually this isn't a big deal in FOSS projects because someone will come along and patch an application to work in a newer glibc and happy days.

But the kicker here is that EAC is compiled directly into the distributed games. Which means distro vendors can't patch it, steam can't patch it and neither can EAC themselves.

The only way to properly fix it (to work with newer glibc) at this point in deployed EACs would be for EAC to update EAC, and then each EAC game updates their EAC and recompiles with the patch.

The other legal issue is that neither EAC nor steam can just come along and just stick a closed source game into a new flatpak with needed libraries, because that would break the games license terms.

Considering many games may not see an update due to inactive devs, it doesn't look good.

At this point best case is that EAC patch to use the modern hash and the game devs update their EAC.

PS: Sorry if I came off a bit brash earlier.. long and bad day...
shorberg 17 Aug
View PC info
  • Supporter Plus
Quoting: CyborgZetaI am not a software developer or a progammer; I am just a regular computer user. So please do not get angry at me for asking this, as I probably don't know what I'm talking about.

But wouldn't running games, and programs/applications in general, inside containers fix this kind of issue? Isn't that one of the goals of Flatpak?

A great question CyborgZeta!

Yes and no. It is really quite overkill to use something like flatpak for the use cases we are talking about, the industry have dealt with this issue for decades and the solution (which is typically used on the windows platform) is to bundle your dependencies either statically in your binary or as dynamic libraries next to your binary.

There are pros and cons to that, for something like a game it is usually "good enough" to bundle only some dependencies given the non-critical nature of games. Programs written in Go(lang) are built as independent static binaries by design. As far as I know this means that they will run pretty much on any system as long as the architecture is compatible (linux x86, windows x86, linux arm, etc).

For drawbacks there are three big ones, one is size. Statically built binaries are larger in size since they bundle everything the program needs inside the binary itself. Another is that if the assumptions those dependencies made about the platform were to change they would still break. Lastly, security. If my program uses curl dynamically and a security flaw is discovered in curl that can be updated independently of my program.

Containerised solutions share the same first two drawbacks and has the third built in "by design" (both good and bad).

Another one you can make a solid argument for is that containerised applications like flatpak add a lot of unnecessary complexity to an already complex chain.

An advantage that a statically linked binary have over a container is reduced resource consumption and a smaller size on disk. A container needs the entire runtime to be present, which will include a ton of stuff the program won't need. Granted, if you install enough containerised applications that rely on the same runtime the differences go away.
Klaas 18 Aug
Quoting: BlackBloodRumMy point was that people (such as yourself) often believed that enterprise level distros were pointless even for servers (…)
That's really insulting and bordering on defamation. Please don't put words in my mouth that I'd never say.

Quoting: CyborgZetaBut wouldn't running games, and programs/applications in general, inside containers fix this kind of issue? Isn't that one of the goals of Flatpak?

You wouldn't be able to use things like the nvidia graphics driver anymore unless you'd include a matching version as well. And then you'd have to fix the kernel.


Last edited by Klaas on 18 August 2022 at 12:03 am UTC
Quinn 18 Aug
There's an easy solution, ban the use of EAC in GNU+Linux native games.
Oh, wait...


Last edited by Quinn on 18 August 2022 at 1:03 am UTC
TheRiddick 18 Aug
All multiplayer games have anti-cheat software. So really, do we want linux to be the single player only game platform?
Zagorim 18 Aug
Quoting: QuinnThere's an easy solution, ban the use of EAC in GNU+Linux native games.
Oh, wait...

Except that Shovel Knight is a native linux game that doesn't use EAC and it's still broken by the glibc update.
I think the glibc devs need to be more careful about the kind of updates they push and the impact they can have.
slaapliedje 18 Aug
View PC info
  • Supporter Plus
Quoting: Zagorim
Quoting: QuinnThere's an easy solution, ban the use of EAC in GNU+Linux native games.
Oh, wait...

Except that Shovel Knight is a native linux game that doesn't use EAC and it's still broken by the glibc update.
I think the glibc devs need to be more careful about the kind of updates they push and the impact they can have.
https://www.phoronix.com/forums/forum/software/linux-gaming/1340528-glibc-2-36-dropping-dt_hash-has-been-breaking-easy-anti-cheat-games-with-steam-play

So according to this article and comments...
The superior method for for which broke (DT_HASH) is to use DT_GNU_HASH. Which has been around for 16 years...

Just to be fair to Linux and all the 'no stable ABI!' This is the GNU library, and isn't controlled at all by the Linux kernel, though clearly just as important.

So this isn't a case of the glibc devs needing to bw careful. They literally just changed the default compile flags to no longer include both methods, because they figured (clearly incorrectly) that people had all shifted to the much more optimized method. Which they have had 16 years to do.

Also sounds like Arch Linux at least has already changed their compile flags and people are testing 2.36-2 which seems to fix the EAC issues (and presumably games like Shovel Knight).

Edit: more technical details here.
https://flapenguin.me/elf-dt-gnu-hash

Sounds to me like some things could end up with massive performance boosts, if it was using the better prelinking!


Last edited by slaapliedje on 18 August 2022 at 9:11 am UTC
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.