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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
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.
17 Likes, Who?
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.
Last edited by const on 15 August 2022 at 11:11 am UTC
4 Likes, Who?
it doesn't constantly break though, things like this have been deprecated for over a decade before removal, everyone else stopped using it before EAC even began development.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.
13 Likes, Who?
Epic using the deprecated DT_HASH
to be more precise: deprecated for 16 (!) years.
16 Likes, Who?
I'm an Arch user, and have been for quite a long time. But I'm starting to grow increasingly worried about the sustainability of their distro model. Honestly, this obsession with dynamically linking everything and updating as soon as possible is a huge house of cards waiting to fall under its own weight.
Why are we okay with the basic model for Linux dependencies being to have *all* the system's dependencies share the same global namespace, while a bunch of overworked (and often underpaid!) enthusiasts make sure that updates happen in lockstep and nothing breaks. Of course things are going to break randomly during updates! There's not enough people willing to donate their time to QA test all of this.
Keeping all this machinery working sounds like a tremendous amount of work, and for what? So that our things break randomly every now and then? So that we can feel good about "memory reuse" while in practice all software we use is Electron crap that happily spins up a chromium instance per window?
The only seemingly valid argument supporting all of this rube goldberg machinery is that we want system updates to automatically patch our applications when a CVE is detected in a system-wide dependency like glibc. But that's (1) Much less of a concern for desktop Linux, which are rarely open to the wide internet in a way that most common exploits could be achieved, and (2) Sysadmins and anyone deploying software on servers are moving away of this traditional distro model in favor of Docker precisely because distro updates break things and environments are non-reproducible.
Anyway... I won't side with Epic on this because they used a deprecated function long after it was documented as such and that's not good practice, but things that work should keep working after an update, I'm tired of this.
At least now we have Valve carefully curating the system updates on Steam OS, so there's less of an incentive to boot up windows when some game stops launching after an upgrade.
Last edited by setzer22 on 15 August 2022 at 1:55 pm UTC
Why are we okay with the basic model for Linux dependencies being to have *all* the system's dependencies share the same global namespace, while a bunch of overworked (and often underpaid!) enthusiasts make sure that updates happen in lockstep and nothing breaks. Of course things are going to break randomly during updates! There's not enough people willing to donate their time to QA test all of this.
Keeping all this machinery working sounds like a tremendous amount of work, and for what? So that our things break randomly every now and then? So that we can feel good about "memory reuse" while in practice all software we use is Electron crap that happily spins up a chromium instance per window?
The only seemingly valid argument supporting all of this rube goldberg machinery is that we want system updates to automatically patch our applications when a CVE is detected in a system-wide dependency like glibc. But that's (1) Much less of a concern for desktop Linux, which are rarely open to the wide internet in a way that most common exploits could be achieved, and (2) Sysadmins and anyone deploying software on servers are moving away of this traditional distro model in favor of Docker precisely because distro updates break things and environments are non-reproducible.
Anyway... I won't side with Epic on this because they used a deprecated function long after it was documented as such and that's not good practice, but things that work should keep working after an update, I'm tired of this.
At least now we have Valve carefully curating the system updates on Steam OS, so there's less of an incentive to boot up windows when some game stops launching after an upgrade.
Last edited by setzer22 on 15 August 2022 at 1:55 pm UTC
4 Likes, Who?
Honestly, this obsession with dynamically linking everything and updating as soon as possible is a huge house of cards waiting to fall under its own weight.
Sounds like you should take a look at NixOS ^^
0 Likes
EagleDelta Aug 15, 2022
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.
While I can understand that attitude, the issue isn't just EAC. Other Linux native games are also broken as well as some other tools. Regardless, non-service based games generally don't keep their games updated and good luck trying to get the industry to change. Microsoft has been fighting this battle with Windows for a couple of decades. Simple fact is that users want their old software, especially games, to continue working. So if we want Linux gaming to succeed, we have to be willing to meet the game devs where they are and not require them to come to us (hint: they won't come to us).
For those that make comments about Debian "Stable" - I work in the tech space, security issues come in on a fairly daily basis and if things aren't updated almost constantly, they will sadly be vulnerable.
2 Likes, Who?
I'm an Arch user, and have been for quite a long time. But I'm starting to grow increasingly worried about the sustainability of their distro model. Honestly, this obsession with dynamically linking everything and updating as soon as possible is a huge house of cards waiting to fall under its own weight.
Why are we okay with the basic model for Linux dependencies being to have *all* the system's dependencies share the same global namespace, while a bunch of overworked (and often underpaid!) enthusiasts make sure that updates happen in lockstep and nothing breaks. Of course things are going to break randomly during updates! There's not enough people willing to donate their time to QA test all of this.
Keeping all this machinery working sounds like a tremendous amount of work, and for what? So that our things break randomly every now and then? So that we can feel good about "memory reuse" while in practice all software we use is Electron crap that happily spins up a chromium instance per window?
The only seemingly valid argument supporting all of this rube goldberg machinery is that we want system updates to automatically patch our applications when a CVE is detected in a system-wide dependency like glibc. But that's (1) Much less of a concern for desktop Linux, which are rarely open to the wide internet in a way that most common exploits could be achieved, and (2) Sysadmins and anyone deploying software on servers are moving away of this traditional distro model in favor of Docker precisely because distro updates break things and environments are non-reproducible.
Anyway... I won't side with Epic on this because they used a deprecated function long after it was documented as such and that's not good practice, but things that work should keep working after an update, I'm tired of this.
At least now we have Valve carefully curating the system updates on Steam OS, so there's less of an incentive to boot up windows when some game stops launching after an upgrade.
Because the alternative which is how software is distributed on Windows (and how the "new" distribution ways of flatpak/snap/whatever) where the responsibility of keeping the shared libraries up to date for security holes and other bugs are shifted onto the developers of each and every single application that you install of it being done just once for your entire OS by a much larger and more competent team.
And thinking that Linux is somehow less impacted by security holes by "something internet something" is naive, we are just as conencted and impacted by this as the Windows users. Now for games in particular, security is rarely an issue what so ever, but if we take applications instead then holes in shared libraries can be exposed by you opening a file in OpenOffice, VLC, GIMP or whatever, it does not have to be an exploit in port X where some Windows subsystem listens to external connections.
The main issue in this particular case though is the "and updating as soon as possible" part which only happens on rolling update distros like arch that want's to be on the bleeding edge for everything instead of the slow and methodical way of Debian or Red Hat.
Last edited by F.Ultra on 15 August 2022 at 3:50 pm UTC
4 Likes, Who?
I'm an Arch user, and have been for quite a long time. But I'm starting to grow increasingly worried about the sustainability of their distro model. Honestly, this obsession with dynamically linking everything and updating as soon as possible is a huge house of cards waiting to fall under its own weight.statically linking wouldn't help here, at least not forever.
Why are we okay with the basic model for Linux dependencies being to have *all* the system's dependencies share the same global namespace, while a bunch of overworked (and often underpaid!) enthusiasts make sure that updates happen in lockstep and nothing breaks. Of course things are going to break randomly during updates! There's not enough people willing to donate their time to QA test all of this.
Keeping all this machinery working sounds like a tremendous amount of work, and for what? So that our things break randomly every now and then? So that we can feel good about "memory reuse" while in practice all software we use is Electron crap that happily spins up a chromium instance per window?
The only seemingly valid argument supporting all of this rube goldberg machinery is that we want system updates to automatically patch our applications when a CVE is detected in a system-wide dependency like glibc. But that's (1) Much less of a concern for desktop Linux, which are rarely open to the wide internet in a way that most common exploits could be achieved, and (2) Sysadmins and anyone deploying software on servers are moving away of this traditional distro model in favor of Docker precisely because distro updates break things and environments are non-reproducible.
Anyway... I won't side with Epic on this because they used a deprecated function long after it was documented as such and that's not good practice, but things that work should keep working after an update, I'm tired of this.
At least now we have Valve carefully curating the system updates on Steam OS, so there's less of an incentive to boot up windows when some game stops launching after an upgrade.
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.
2 Likes, Who?
EagleDelta Aug 15, 2022
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.
Last edited by EagleDelta on 15 August 2022 at 5:59 pm UTC
6 Likes, Who?
I'm an Arch user, and have been for quite a long time. But I'm starting to grow increasingly worried about the sustainability of their distro model. Honestly, this obsession with dynamically linking everything and updating as soon as possible is a huge house of cards waiting to fall under its own weight.
I feel the same way sometimes, Arch likes to spin their wheels.
I also generally don't like the way Arch compiles things (I want optimizations, not hardening flags and stack canaries, and I don't want my compilers producing position independent objects by default, thank you) so I change it.
Arch really jumped the gun on glibc this time. I maintain two setups on this box, a customized Manjaro* that I mostly maintain myself, and a custom "from scratch" system that I use for more serious stuff (and I also have that one on other boxes). I also have a customized Slackware 15 on one box. I keep them all binary compatible so I can run some builds on all systems.
(* A Manjaro install is just what I started out with. I was attracted by the more delayed update cycles. I actually follow Arch and edit their PKGBUILDs. I have a bloody novel's worth of text in IgnorePkg lines in pacman.conf lol)
I'm still paying for glibc 2.36. I don't do anti-cheat in games (I only like single player) but I had a lot of compile time issues to work around when bootstrapping toolchains and recompiling/upgrading things. I haven't had any binary compatibility issues though.
While I get angry, I always come back to the mindset that at least Arch provides me with a full multilib system environment that I can work with. There's no way I'd use some Ubuntu or Fedora distro or their ilk because those distros make it difficult for the way I do things.
I don't like containers, and I won't run software like that, so Arch base it is for me.
1 Likes, Who?
Philadelphus Aug 15, 2022
For those that make comments about Debian "Stable" - I work in the tech space, security issues come in on a fairly daily basis and if things aren't updated almost constantly, they will sadly be vulnerable.Hence why Debian stable includes frequent security backports fixing issues, without breaking functionality.
That's not to say that model is perfect, because there is no perfect model (or there'd be a single Linux OS); a few months ago I moved many of the programs I use (like Inkscape, Blender, GIMP, etc.) over to Flatpak to get updates more frequently. But for the underlying OS I like the stability and security.
5 Likes, Who?
I ran into this a few weeks ago and had to install the flatpak version of Steam to get around this issue.
0 Likes
The greatest weakness of Linux (some say that it is a strength) is not having its own libc. I would like to see Linux being the maintainer of glibc and refusing to break in every release and put the blame in the developer.
1 Likes, Who?
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?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'm not talking about linking libraries, because you can solve the issue with flatpacks and similar or by just providing the correct ones.
We're talking about a technology old at least 16 years badly required by incompetent developers here.
And there is 16 years old windows software that can be run wothout issues under proton today and is not compatible anymore with windows itself.
0 Likes
The greatest weakness of Linux (some say that it is a strength) is not having its own libc. I would like to see Linux being the maintainer of glibc and refusing to break in every release and put the blame in the developer.That's like saying Linux should maintain its own distribution.
There are alternatives on every end of the spectrum. Some people are happy with the GNU libc, others are happy with systemd, some are happy with both, and even if you're neither, you still have the choice to run musl and sysvinit instead... or something completely different, and *still* not having to leave the Linux ecosystem.
So yes, I do see it as a strength, or maybe part of Linux' immune system, that "Linux" is "GNU/Linux" if and only if you make it so. Or conversely of course, "GNU/Linux" is only as much "Linux" as you make it, if you want to go that route. It's all about freedom of choice.
0 Likes
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.
1 Likes, Who?
Patreon
PayPal
See more from me