You can sign up to get a daily email of our articles, see the Mailing List page.
We do often include affiliate links to earn us some pennies. See more here.

Easy Anti-Cheat not working on Linux? Seems a glibc update broke it

By - | Views: 20,737

News has been doing the rounds for a little bit about Easy Anti-Cheat (EAC) suddenly not working after system updates for some users, turns out it's an issue with glibc.

Reported on GitHub over a week ago, the issue has been growing as more and more users have been updating their systems. Only certain Linux distributions are affected, mainly those that pull in package updates a lot faster like Arch and derivatives.

EAC is not the only thing broken as there have been reports about the frame limiter libstrangle also being broken by it, the game Shovel Knight and there's probably more too.

In the upstream bug report for glibc there's been plenty of back and forth on it. Hopefully a true resolution will be found. Until then, multiple distributions seem to be readying up an update (Arch looks to have it out now) that reverts the change to get EAC games to work once again. So if you haven't updated recently, it might be an idea to hold off for just a little bit until this situation is sorted.

Article taken from GamingOnLinux.com.
19 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
30 comments
Page: «3/3
  Go to:

Lamdarer 15 Aug
No trouble on Manjaro Testing for me, could even play Warhammer: Vermintide 2
I'm on Manjaro-Testing, updated fine. I'm not ready for Arch
TheRiddick 16 Aug
I can't really find the reason for why they removed this function from glibc (other then, its old and boring)

Developers just got bored and wanted to break something?


PS. Manjaro is basically ARCH with more safety wheels... (or restrictions/booby-traps if you like!)


Last edited by TheRiddick on 16 August 2022 at 4:25 am UTC
const 16 Aug
Quoting: EagleDelta
Quoting: kokoko3kstatically linking wouldn't help here, at least not forever.
glibc stands between the kernel and userspace.
So if you don't plan to stay with an outdated kernel forever, a statically linked executable will face the issue sooner or later.
We are talking about a deprecated feature since 16 years, while the new feature replacing it has been available since 2 decades.
Somebody, please, explain me WHY on earth one should still rely on it with a software written today.
This is not a glibc fault.

Good blog post about the problem: https://blog.hiler.eu/win32-the-only-stable-abi/

TL;DR -

* DT_GNU_HASH has been around for 16 years, but has very little documentation associated with it. Especially compared to DT_HASH.
* For those 16 years, it was Glibc who provided the compatibility and overrode the defaults for everyone and there never were any easy-to-spot deprecation warnings.
* The constant changing of libraries in Linux with all disregard for applications targeting them is why for most GameDevs, Win32 is a far more stable ABI to target than anything provided in Linux.

And my personal opinion (from experience) - you are not going to get GameDevs to conform to the "Linux" way or the "Right" way of doing these things. If you want gaming on Linux, we have to go to the GameDevs.

I think at this point, production software has become a lot more important then *native* gaming. This once again shows linux ain't a platform to just target with one build and mostly because of core libraries changing their ABI.
const 16 Aug
Quoting: Valck
Quoting: kokoko3kHow is it possible that I know more than a easycheat dev when it comes to this particular issue, given that I'm not a dev?
Right?
Instead of people shouting "glibc broke my games" they should instead shout "Anticheat broke my game", that's what's actually wrong here.

But more to the point, I can definitely see Epic intentionally playing dumb. It hurts Linux, which they hate, and it hurts their competitor, which they certainly don't have much love for, either. And in the end, it's a simple fix where they can shine and bask in their glory as the saviours of both.
That may be a bit over the top, but still... keep that in mind.

No, it's simply both. If Epic had used the non-deprecated API, this would have still hit a lot of binaries. I bet Shovel Knight is just the most popular example and there are at least dozens of apps to follow.
And why should applications/games that were build 16 years ago, when this was still supported api, just stop working on modern distributions? And with glibc, afaik, this can't even be solved by bundling it in a flatpak.

As a student, I by chance made quite some money by servicing dozens of dairy farmers who were essentially stuck with win95 because their breeding register application (yes, those exist, are damn expensive, somewhat legally required and you can't really move from one to another) was never updated and simply refused to run on anything other then win95/98. I ironically solved that with wine and these farmers are still very happy about that.
Now imagine that was a Linux application...


Last edited by const on 16 August 2022 at 6:58 am UTC
I just recently reinstalled my Nobara to Manjaro, just to keep myself up to date with what's going on with Manjaro. Surprisingly, glibc 2.36-1 only lasted for... what, a week? They held back 2.36 for as long as they can and then blitzed through the Testing for 2.36-2, releasing on Stable today.

Between that, as well as having the most painless automated installer I've had -- seriously, I wish more distro offers the choice of swap/swapfile/swap-with-hibernate + filesystem choosing and automated autosnap setup for filesystem that supports snapshots -- I feel like the recent Manjaro backlash is overblown.

I get that they have their issues, but I can definitely see the merit of Manjaro as a whole now. Considering my main 'dependency hell' on AUR/Arch has been the lib32-sane insanity for using Office via CrossOver and that WoW64 is coming sometimes this year or next year, I think I might just migrate back to Manjaro for my main machine sometimes (though I'd rather go with Pop, if they eventually have autosnap -- edit: huh, they will for 22.10, in that case Pop+distrobox-archlinux would be my preferred best-of-all-world choice).


Last edited by fenglengshun on 16 August 2022 at 8:08 am UTC
Eike 16 Aug
View PC info
  • Supporter Plus
Quoting: F.UltraNow for games in particular, security is rarely an issue what so ever

Why do you think so? Many games communicate over the internet, and I fear user security is not among the first 26 concerns of many game developers...
Quoting: const
Quoting: RustyTo be fair to glibc, this is a problem on the part of Epic using the deprecated DT_HASH instead of DT_GNU_HASH. EAC's Linux implementation is frustratingly half-baked. It really feels like Epic is the biggest barrier to gaming on Linux now.

Question is: why does glibc constantly break the API(/ABI)? It's a damn c library and should be backwards compatible. If at all, functions should be altered on major releases, so distributions have a chance to handle such stuff. Couldn't they just have redirected that damn call? It's really infuriating they don't care for backwards compatibility at all and this hurts linux in many ways.

Yeah also I've heard from some sources that they never officially depreciated it so no devs knew it was depreciated until it was removed from glibc entirely. In which case, it might not have been on epic but rather on glibc.
Grogan 16 Aug
I was looking over Arch's latest glibc PKGBUILD last night (though I didn't do it, I don't really care about this DT_HASH issue), and they have actually reverted the glibc change with a patch.

https://github.com/archlinux/svntogit-packages/blob/packages/glibc/trunk/reenable_DT_HASH.patch

A followup just to be fair, since we were bitching about Arch.
F.Ultra 17 Aug
View PC info
  • Supporter
Quoting: Eike
Quoting: F.UltraNow for games in particular, security is rarely an issue what so ever

Why do you think so? Many games communicate over the internet, and I fear user security is not among the first 26 concerns of many game developers...

My reasoning here is that those games does not communicate randomly over the Internet but almost always only home (usually over https so the remove url cannot be spoofed easily either) and that the communication initiation is always out-going and not in-going (aka the game does not listen to incoming connections) and that the processing of the data on this communication is handled by the game itself and not by some shared library (which means that there are no benefits to fix the libs).
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.