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

I'm on Manjaro-Testing, updated fine. I'm not ready for Arch

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

statically 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.

How 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

Now 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...

To 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.

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.

Now 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).