[SOLVED] glibc, DT_HASH, glibc-eac (Easy Anti-Cheat)

Archerino · 2024-03-24 19:06:36

I love to use Arch Linux to play my favorite video games. However, since the release of glibc 2.39-1 I am forced to use glibc-eac from the AUR. This is because the (regular) glibc package from the core repository lacks the DT_HASH patch for games using EAC (Easy Anti-Cheat).

glibc is an essential package and grabbing it from the AUR or source is not a good thing for stability.

Apparently it has been suggested to install the flatpak version of steam (see closed bug tracker). I feel that's hardly a solution as there are many people who would love to keep on using regular steam for increased performance, being able to use one's /home directory etc.

This is problem to the many Arch gamers out there. Many games use EAC and there's quite of number of games that break because of the issue with glibc.
I am wondering if there's an awareness of the magnitude of the problem. What is the likelihood of this being resolved?

Last edited by Archerino (2024-04-20 08:55:27)

Scimmia · 2024-03-24 22:26:59

So the situation is that some proprietary software decides to use a deprecated hash table. Upstream glibc finally drops it after what, 10+ years? And things break. Blame EAC.

PeterJansen · 2024-03-25 13:04:44

Archerino addresses a valid point, this is a serious problem. However, the argumentation could be a bit better.

1. As he pointed out, glibc is one of the core packages of the system, is it desired that a % of the Arch-users is going to use glibc via the AUR instead of via the repositories? It seems like easy breaking territory to me.

2. I agree with him that the Steam Flatpak is not a solution, but he doesn't properly motivate why, it is not really about what we prefer to do. The problem with the Steam flatpak is that the performance is worse than with regular Steam in certain cases and in some other cases the game just won't run at all with Steam Flatpak while it will run with the latest regular version of Steam. Linux YouTuber (he also finished at least the bachelor of computer science so he knows a bit what he talks about in regard to software) Brodie Robertson addressed that in his video about EAC being broken again on Arch.

3. Archerino strongly undersells the scale of the problem with "hundreds of users", we know from the Steam Hardware Survey (far from perfect but it gives some indication) that a high % of the Linux-gamers uses Arch, it already was roughly tied with Ubuntu as the most popular distro for gaming before the SteamDeck was sold, I assume that everybody here knows what the SteamDeck is. One of the games for which currently EAC on Arch is broken is Apex:Legends, this is the 3rd most popular Battleground shooter (at a large distance from Fortnite and PUBG), which probably is the most popular genre of games in the last years. I myself play Apex:Legends at times, it just can't start with glibc from the Arch-repositories and it starts with glibc-eac via the AUR. I can understand that not everybody in the Arch-team appreciates gaming and that is fine, but please appreciate that many of us do like to game and that gaming is as common on Linux as it is on Windows these days with how good wine and especially dxvk have gotten, also assisted by tools like Lutris and Steam Proton. Common users now use Linux for gaming as they do on Windows.

In reply to Scimmia, this is not a new problem. This is a repeat of moves from 2 years ago. Back then the packager for Arch started to compile glibc differently and it broke EAC-support. In my opinion he made the correct choice to revoke it after many gamers pointed out this problem. The big question: why did he revoke it 2 years ago and not do it now? What changed? We know that these game-developers still use a deprecated hash table. Do some people hope that these game-developers will finally learn it by breaking Arch on purpose for those games? I give that 0% chance. Is there any valid reason to not support the "deprecated" hash-table? What harm does result from supporting both? A bit more data-usage while 2 TB SSD's cost less than $90? If for most users that would be problematic then it is fine but if no user its system gets any harm from also using the deprecated hash-table then the correct choice is to support that, in my opinion.

Proposed solution: offer also glibc-eac in the repositories. The real repositories, not the AUR-scripts. Everybody would be happy with that solution. I appreciate the efforst from all the people who keep Arch going, please don't take any offense from this post, I mereley address a current problem.

Last edited by PeterJansen (2024-03-25 13:08:51)

fmc000 · 2024-03-25 15:23:10

AFAIK, Arch followed what upstream did - they didn't change anything on their own. I may be wrong, though, but if I'm right just complain with upstream and not with Arch.

Another possibility, switch to a distro that still offers that patch by default.

Head_on_a_Stick · 2024-03-25 18:18:01

PeterJansen wrote:

offer also glibc-eac in the repositories. The real repositories, not the AUR-scripts.

That is a ridiculous request. Why can't you use the AUR?

MacTavishAO · 2024-03-26 22:36:06

I'm the maintainer of glibc-eac on AUR and I would love to delete that package after official repos bring the patch back.

For me, it's pragmatic thing to do. I don't have any data but if steam hardware survey is anything to go by to deduct, a considerable amount of arch users are gamers as well. One day, official glibc package is going to be updated along with rebuild of every package that depends on it. It will end up breaking maybe hundreds of installations if users are not careful. It's only a matter of time before something that drastic happens. Think of the flood this forum or subreddit is going to get when that happens.

From my point of view, including this patch is net win in long term.

Last edited by MacTavishAO (2024-03-26 22:44:54)

Allan · 2024-03-26 23:22:05

MacTavishAO wrote:

One day, official glibc package is going to be updated along with rebuild of every package that depends on it.

No it won't...

Archerino · 2024-04-03 13:30:15

Thank you all for commenting.
I agree with MacTavishAO that it would be a net win to include this patch in the official repos. Futhermore, I agree with PeterJansen that there doesn't appear to be reason not to include the deprecated hash table.
Even if upstream changed something, including it doesn't seem to have real disadvantages while it could help out the many gamers out there.

ugjka · 2024-04-03 14:49:12

What will happen is that eventually all other distributions will adopt the new glibc and then the EAC developers will finally be forced to update their software

Last edited by ugjka (2024-04-06 21:34:14)

xerxes_ · 2024-04-10 11:11:06

You can download previous arch linux glibc-eac enabled version, extract it to /usr/local/lib/ and preload when you run steam or get rid of things needing glibc-eac from games.

Archerino · 2024-04-20 08:56:29

Marking thread as solved. Apparently one of my favorite games (Apex Legends) is currently working with regular glibc. That could still mean other games are affected though.

Last edited by Archerino (2024-04-20 08:57:56)

Arch Linux

#1 2024-03-24 19:06:36

[SOLVED] glibc, DT_HASH, glibc-eac (Easy Anti-Cheat)

#2 2024-03-24 22:26:59

Re: [SOLVED] glibc, DT_HASH, glibc-eac (Easy Anti-Cheat)

#3 2024-03-25 13:04:44

Re: [SOLVED] glibc, DT_HASH, glibc-eac (Easy Anti-Cheat)

#4 2024-03-25 15:23:10

Re: [SOLVED] glibc, DT_HASH, glibc-eac (Easy Anti-Cheat)

#5 2024-03-25 18:18:01

Re: [SOLVED] glibc, DT_HASH, glibc-eac (Easy Anti-Cheat)

#6 2024-03-26 22:36:06

Re: [SOLVED] glibc, DT_HASH, glibc-eac (Easy Anti-Cheat)

#7 2024-03-26 23:22:05

Re: [SOLVED] glibc, DT_HASH, glibc-eac (Easy Anti-Cheat)

#8 2024-04-03 13:30:15

Re: [SOLVED] glibc, DT_HASH, glibc-eac (Easy Anti-Cheat)

#9 2024-04-03 14:49:12

Re: [SOLVED] glibc, DT_HASH, glibc-eac (Easy Anti-Cheat)

#10 2024-04-10 11:11:06

Re: [SOLVED] glibc, DT_HASH, glibc-eac (Easy Anti-Cheat)

#11 2024-04-20 08:56:29

Re: [SOLVED] glibc, DT_HASH, glibc-eac (Easy Anti-Cheat)

Board footer