GLIBC update broke EAC for most games that use it
Yeah Confirming. Bloodhunt EAC breaks with glibc 2.36
Apex Legends is still fine. Apex using the older non-EOS EAC i guess?
Just happened to me.
Happen to me with Elden Ring
can confirm, also for Video Horror Society.
Confirmed on Multiversus.
Try it at workaround :
pacman -U https://archive.archlinux.org/packages/g/glibc/glibc-2.35-6-x86_64.pkg.tar.zst https://archive.archlinux.org/packages/l/lib32-glibc/lib32-glibc-2.35-6-x86_64.pkg.tar.zst
EDIT : Nop, don't try it, it broke my system wich need glibc 2.36...
Little bit of a workaround: use steam flatpak until the issue gets fixed.
also broken for me with elden ring
Edit: as expected, a workaround is to use the flatpak steam version, you can just add your steam library as a filesystem and skip having to install the games again
I was having problems with glibc 2.35 and rogue company
can confirm other EAC games broke with 2.36 now
Confirmed for GNU libc 2.36 on Arch Linux 5.18.15-arch1-2 on the following games:
Multiversus
Dragonball FighterZ
Confirmed on Multiversus.
~Try it at workaround :
pacman -U https://archive.archlinux.org/packages/g/glibc/glibc-2.35-6-x86_64.pkg.tar.zst https://archive.archlinux.org/packages/l/lib32-glibc/lib32-glibc-2.35-6-x86_64.pkg.tar.zst~EDIT : Nop, don't try it, it broke my system wich need glibc 2.36...
Yea same lmao, thankfully easily fixable by updating with pacman on a live usb inside chroot
Can Confirm, on Arch Linux. Played a few games in the morning (on Multiversus), ran a pacman update, came back to this issue
You can safely(ish) downgrade glibc with the "downgrade" utility on the AUR. Just make sure to include lib32 and gcc-libs. I forgot GCC-libs and had to downgrade from the command line.
sudo downgrade glibc lib32-glibc gcc-libs
Multiversus is able to start successfully after the downgrade.
Experienced the same issue. The steam flatpak works so I'll maybe switch to that indefinitely when i get gamemode working
You can safely(ish) downgrade glibc with the "downgrade" utility on the AUR. Just make sure to include lib32 and gcc-libs. I forgot GCC-libs and had to downgrade from the command line.
sudo downgrade glibc lib32-glibc gcc-libs
Multiversus is able to start successfully after the downgrade.
Thank you! I was midtype of reverting it but you made it much much easier. Whenever I try downgrading though, it borks my system (I get faced with a stuck "/dev/sda: clean" bootup screen, reverting downgrade fixes this). Specifically, I think its the gcc-libs breaking dependency with gcc-libs=12.1.1-4. I'll mess around a bit more, but thanks!
Edit: After downgrading gcc as well, it has no error message about dependencies, but won't boot up multiversus nor steam, weirdly
You can safely(ish) downgrade glibc with the "downgrade" utility on the AUR. Just make sure to include lib32 and gcc-libs. I forgot GCC-libs and had to downgrade from the command line.
sudo downgrade glibc lib32-glibc gcc-libsMultiversus is able to start successfully after the downgrade.
Did it with :
sudo downgrade glibc lib32-glibc gcc-libs lib32-gcc-libs gcc
gcc 12.1.0
gcc-libs 12.1.0
glibc 2.35
lib32-gcc-libs 12.1.0
lib32-glibc 2.35
Thank you
If you won't install downgrade, you can do :
pacman -U https://archive.archlinux.org/packages/g/glibc/glibc-2.35-6-x86_64.pkg.tar.zst https://archive.archlinux.org/packages/l/lib32-glibc/lib32-glibc-2.35-6-x86_64.pkg.tar.zst https://archive.archlinux.org/packages/l/lib32-gcc-libs/lib32-gcc-libs-12.1.0-3-x86_64.pkg.tar.zst https://archive.archlinux.org/packages/g/gcc-libs/gcc-libs-12.1.0-3-x86_64.pkg.tar.zst https://archive.archlinux.org/packages/g/gcc/gcc-12.1.0-3-x86_64.pkg.tar.zst
Thank you!
sudo downgrade glibc lib32-glibc gcc-libs lib32-gcc-libs gcc
gcc 12.1.0
gcc-libs 12.1.0
glibc 2.35
lib32-gcc-libs 12.1.0
lib32-glibc 2.35
That fixed it no problem!
I wish someone would take the time to bisect rather than downgrade and forget. This needs a bisect in order to get it fixed properly. I performed the bisect on the Rogue Company issue. Fortunately Fedora is not on glibc 2.36 yet, and I also just don't have the time
I wish someone would take the time to bisect rather than downgrade and forget. This needs a bisect in order to get it fixed properly. I performed the bisect on the Rogue Company issue. Fortunately Fedora is not on glibc 2.36 yet, and I also just don't have the time
how would I do the bisect without messing up my system? would I use a vm or distrobox or something? and how would I easily test it, since it would take forever to test each commit
I wish someone would take the time to bisect rather than downgrade and forget. This needs a bisect in order to get it fixed properly. I performed the bisect on the Rogue Company issue. Fortunately Fedora is not on glibc 2.36 yet, and I also just don't have the time
Like Etaash I would like to know how would one go about doing this.
Sorry about that, clicked "close with comment" instead of "comment" when posting my reply
bisecting this seems kinda impossible without potentially breaking the system. I downgraded by using downgrade tool for now and everything works again.
[2022-08-03T14:39:42+0300] [ALPM] downgraded glibc (2.36-1 -> 2.35-6)
[2022-08-03T14:39:43+0300] [ALPM] downgraded lib32-glibc (2.36-1 -> 2.35-6)
[2022-08-03T14:42:11+0300] [ALPM] downgraded gcc-libs (12.1.1-4 -> 12.1.0-3)
[2022-08-03T14:42:11+0300] [ALPM] downgraded binutils (2.38-7 -> 2.38-6)
[2022-08-03T14:42:12+0300] [ALPM] downgraded gcc (12.1.1-4 -> 12.1.0-3)
[2022-08-03T14:42:12+0300] [ALPM] downgraded gcc-fortran (12.1.1-4 -> 12.1.0-3)
[2022-08-03T14:42:12+0300] [ALPM] downgraded gcc-objc (12.1.1-4 -> 12.1.0-3)
[2022-08-03T14:42:12+0300] [ALPM] downgraded lib32-gcc-libs (12.1.1-4 -> 12.1.0-3)
[2022-08-03T14:42:12+0300] [ALPM] transaction completed
But its just delaying the issues. had to also downgrade thunderbird for example as its latest version already requires glibc 2.36
This also may break the system at some point if more things starting to require updated glibc
NOTE! Do not do it unless you know what you are doing! This may break your entire system if you keep updating other system packages while some are rolled back and locked to older versions!
I wish someone would take the time to bisect rather than downgrade and forget. This needs a bisect in order to get it fixed properly. I performed the bisect on the Rogue Company issue. Fortunately Fedora is not on glibc 2.36 yet, and I also just don't have the time
Compiling glibc and the corresponding packages takes over a couple of hours on my potato. It would take quite a few days for me to just compile packages from every commit. I would think Proton devs would have the resources to bisect much quicker, I mean Valve is going to need it working for Steam Deck updates.
Would it be worth it to file a bug report on the glibc tracker without bisecting first? I don't see one on there yet. I imagine they would say it's an EAC problem but I guess we would know more once we figure which commit b0rked it.
Is the breakage reproducible using LD_LIBRARY_PATH without downgrading glibc system-wide ?
I've seen a Proton EAC Runtime update lately, did it fix anything for anybody?
EDIT: nevermind, SteamDB shows only dll changes for yesterday's update, don't think it has anything to do with GLIBC compatibility: https://steamdb.info/depot/1826331/history/?changeid=M:7482036680883698310
@thaewrapt Yeah, that update to Proton EAC Runtime is supposed to fix EAC in Vermintide 2, not glibc–related issues with EOS EAC.
Would it be worth it to file a bug report on the glibc tracker without bisecting first? I don't see one on there yet. I imagine they would say it's an EAC problem but I guess we would know more once we figure which commit b0rked it.
My understanding is that glibc is supposed to have a stable API and ABI, so I think this per definition is a glibc issue. Unless EAC is using private API, of course.
downgrading glibc can break lots of stuff, so be careful. My terminal emulator kitty for example refused to work with 2.35
Downgrading didn't solve anything sadly, it actually broke some stuff.
And flatpak didn't help either.
Downgrading didn't solve anything sadly, it actually broke some stuff.
And flatpak didn't help either.
If Flatpak doesn't solve it, you're experiencing a different issue. Flatpak has not upgraded its glibc yet to my knowledge (and won't until the Freedesktop 22.08 SDK releases and Steam upgrades to it).
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1204543127
I know it's cool and useful to include instructions for downgrading, but a less experienced user will just accept this as a fix, blindly run it and potentially break their system. So please either wait or use this with caution.
safest workaround right now is to just switch to flatpak steam.
Downgrading didn't solve anything sadly, it actually broke some stuff.
And flatpak didn't help either.If Flatpak doesn't solve it, you're experiencing a different issue. Flatpak has not upgraded its glibc yet to my knowledge (and won't until the Freedesktop 22.08 SDK releases and Steam upgrades to it).
The thing is, the flatpak version doesn't boot games at all.
The thing is, the flatpak version doesn't boot games at all.
Please don't post about other unrelated issues in this thread
The thing is, the flatpak version doesn't boot games at all.
Please don't post about other unrelated issues in this thread
I only mentioned it because I wanted to point out that my problem is, indeed, the same as OP, no need to get sensitive.
your issues seem to be beyond the scope, since the games run from flatpak just fine for anyone where their only issue is that the glibc update broke EAC.
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1206548973
Personally my issue is the same as OP.
When I try to boot games from my "normal" steam, I get the same screens as in the screenshots. Exactly the same.
When I try to use the flatpak version the game does not boot, at all. And that's a different issue so I won't go in further details about it here.
But the problem I have IS the same as OP.
Flatpak quite literally cannot access my games. I install my games on an external drive because I installed Arch on my 250 gb ssd.
I'm sure lots of people do the same, It's not that great...
Flatpak quite literally cannot access my games. I install my games on an external drive because I installed Arch on my 250 gb ssd. I'm sure lots of people do the same, It's not that great...
While I understand providing support for Flathub's packaging of Steam is out of scope for this issue, you can use Flatseal to give Flathub's Steam package permission to access your external drive: https://flathub.org/apps/details/com.github.tchx84.Flatseal
Did someone ask about it in the glibc mailing lists?
https://www.gnu.org/software/libc/involved.html
libc-help seems to be the place to discuss this problem.
I wish someone would take the time to bisect rather than downgrade and forget. This needs a bisect in order to get it fixed properly. I performed the bisect on the Rogue Company issue. Fortunately Fedora is not on glibc 2.36 yet, and I also just don't have the time
how would I do the bisect without messing up my system? would I use a vm or distrobox or something? and how would I easily test it, since it would take forever to test each commit
a spare system for bisecting would be needed. and no, you dont have to risk hosing the entire system. the main problem with upgrading glibc is that applications upgraded alongside it expect the 2.36 version header. SO on Arch you would:
- completely downgrade back to 2.35.
- Find the last glibc commit in 2.35 before 2.36 was released
- Find the most recent glibc commit in 2.35 from the version installed by the downgrade.
- Download the PKGBUILD for glibc and modify it to use glibc git and checkout commits in between those two for bisecting.
- repeat 4, for your standard bisect procedure.
Here's an example. Let's say you have 100 commits between 2.35 and 2.36. Commit # 100 is the "2.36 version change". -- it's just a text version change, not an actual other coding change. So now you know you need to check commits 1-99. Now let's say version 2.35 of glibc on arch was compiled on commit 35. Then you know commit 35 is a good commit, and that narrows your search range down to 36-99. So, you pick a commit in the middle of 36-99, something like 67. Test commit 67, if it fails, your problem is between commits 36-67. If it succeeds, your problem is between 67-99. Rinse repeat this process until you "bisect" the commit groups down to a single commit.
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1206658605
ok so that's how you avoid testing every commit, I wonder how I have never thought of that lol
Replying to [#6051 (comment)](https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1206548973)
Personally my issue is the same as OP. When I try to boot games from my "normal" steam, I get the same screens as in the screenshots. Exactly the same. When I try to use the flatpak version the game does not boot, at all. And that's a different issue so I won't go in further details about it here. But the problem I have IS the same as OP.
If you want to get your games running and can't (or would rather not) downgrade glibc, it's worth checking out the wiki for Flathub's Steam package, and/or opening an issue on their tracker.
Any problems with getting the Flathub build of Steam going should be discussed over that-a-way so that this issue can focus on the glibc/EAC breakage.
ok so that's how you avoid testing every commit, I wonder how I have never thought of that lol
It's a standard binary search, git will automate the checking for you with https://git-scm.com/docs/git-bisect
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1206723532
Yes that's the thing. I don't want to get the flathub version to work.
I want the version I install from my package manager.
I never asked for help getting the flathub version to work on this thread or anywhere. I only mentioned it.
We should stop talking about flathub/flatpak, I think it only clutter the thread. I regret ever mentioning it.
ok so that's how you avoid testing every commit, I wonder how I have never thought of that lol
It's a standard binary search,
gitwill automate the checking for you with https://git-scm.com/docs/git-bisect
I have never done a bisect before since I just assumed that I would have to test every single commit, luckily torvalds has got my back so that's nice
I finally managed to get glibc to build and install properly and now I'm bisecting it.
Bisect done:
e47de5cb2d4dbecb58f569ed241e8e95c568f03c is the first bad commit
commit e47de5cb2d4dbecb58f569ed241e8e95c568f03c
Author: Florian Weimer <[email protected]>
Date: Fri Apr 29 16:37:51 2022 +0200
Do not use --hash-style=both for building glibc shared objects
The comment indicates that --hash-style=both was used to maintain
compatibility with static dlopen, but we had many internal ABI
changes since then, so this compatiblity does not add value anymore.
Reviewed-by: Carlos O'Donell <[email protected]>
Makeconfig | 9 ---------
Makerules | 7 -------
config.make.in | 1 -
configure | 28 ----------------------------
configure.ac | 16 ----------------
5 files changed, 61 deletions(-)
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=e47de5cb2d4dbecb58f569ed241e8e95c568f03c
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1206888814
beat me to it lol :(
beat me to it lol :(
How far did you get?
beat me to it lol :(
How far did you get?
error: 'SHADOW_STACK_POINTER_OFFSET' undeclared here (not in a function); did you mean 'SHADOW_STACK_POINTER_SIZE'
I was gonna try a different commit
beat me to it lol :(
How far did you get?
error: 'SHADOW_STACK_POINTER_OFFSET' undeclared here (not in a function); did you mean 'SHADOW_STACK_POINTER_SIZE'I was gonna try a different commit
For such things, do git bisect skip to indicate the commit was neither good nor bad, just untestable. Its main use is for build failures like this which are unrelated to your problem.
beat me to it lol :(
How far did you get?
error: 'SHADOW_STACK_POINTER_OFFSET' undeclared here (not in a function); did you mean 'SHADOW_STACK_POINTER_SIZE'I was gonna try a different commitFor such things, do 'git bisect skip'.
I wasn't using git bisect, I just picked a random commit from around 4 months ago, idk how you would use a git bisect with a pkgbuild
"The comment indicates that --hash-style=both was used to maintain
compatibility with static dlopen"
I guess the valve devs have to fix something related to dlopen?
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1206898344
I just cloned a copy of glibc in another directory and used bisect in
that copy, and copied the commit IDs it gave me to the PKGBUILD.
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-120688881
Do not use --hash-style=both for building glibc shared objects
This is the ld man page's explanation of this option:
--hash-style=style
Set the type of linker's hash table(s). style can be either "sysv" for classic ELF ".hash" section, "gnu" for new style GNU ".gnu.hash" section or "both" for both the classic ELF ".hash" and new style GNU ".gnu.hash" hash tables. The default depends upon how the linker was configured, but for most Linux based systems it will be "both".
The difference this produces in libc.so.6 is that the "bad" binary does not have the .hash section (below is the output of objdump -x on the "good" binary):
Dynamic Section:
NEEDED ld-linux.so.2
SONAME libc.so.6
INIT_ARRAY 0x0021f2dc
INIT_ARRAYSZ 0x0000000c
HASH 0x00219284
GNU_HASH 0x00000258
[...]
3 .gnu.hash 00005324 00000258 00000258 00000258 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
[...]
18 .hash 00004378 00219284 00219284 00219284 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
However, I do not know why this would break EAC. Perhaps EAC looks at this section. Or the removal of this section has a side effect that ultimately results in EAC not working.
For pacman distros users, I have modified Arch's glibc 2.36 PKGBUILD to include a revert for the commit Frogging101 bisected (thanks again !), which seems to be enough of a fix for EAC to work as it was on 2.35. Multiversus, Brawlhalla and Video Horror Society were tested successfully.
It also needed a couple changes to build (using system localedef and disabling two tests).
Here's the tree: https://github.com/Frogging-Family/glibc-eac
And here are prebuilt packages: https://github.com/Frogging-Family/glibc-eac/releases
(install with sudo pacman -U packagename.pkg.tar.zst)
using system localedef
Oh yeah, I had to do this too. I feel like it should use the system localedef anyway, because compiling a new localedef against a new glibc and then trying to run it with the old one seems like it's likely to fail.
(sorry, getting offtopic)
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1207123916
Can confirm on my Arch installation this fixes the EAC issue, tested with Elden Ring. I used the pre-built packages linked above. Thank you so much for your work on this!
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1207123916
Thank you, this works great in the meantime! How would I go about installing the regular version when it's fixed? Would a sudo pacman -Syu pull it up automatically?
Thanks @Tk-Glitch and @Frogging101! I hope upstream (Epic or GNU LibC itself) fix this soon as possible.
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1207127403
pacman -S glibc should install the official one from the repos.
Thank you, this works great in the meantime! How would I go about installing the regular version when it's fixed? Would a
sudo pacman -Syupull it up automatically?
The package has the same name as the regular Arch one, so when the 2.36-2 package will be pushed to Arch's repos, you'll be notified about the update like nothing happened. Hopefully that package update will mean the fix is in.
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1207123916
Hey glitch, thanks for your work, at the moment after installing the package you shared I'm getting this error when I try to boot games with EAC, tested with multiversus and elden ring:
https://i.imgur.com/5s4Nnzs.png
Is there any way I can provide useful logs to you?
Replying to [#6051 (comment)](https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1207123916)
Hey glitch, thanks for your work, at the moment after installing the package you shared I'm getting this error when I try to boot games with EAC, tested with multiversus and elden ring: https://i.imgur.com/5s4Nnzs.png
Is there any way I can provide useful logs to you?
Did you reboot after installing the package? I have seen similar issues for people that got fixed with a reboot. Also, don't use flatpacked steam client.
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1207123916
I ran a system update (to get some reproducible state), ran
sudo pacman -U https://github.com/Frogging-Family/glibc-eac/releases/download/test/glibc-2.36-1-x86_64.pkg. tar.zst https://github.com/Frogging-Family/glibc-eac/releases/download/test/lib32-glibc-2.36-1-x86_64.pkg.tar.zst
but still got the original anti cheat error with Elden Ring and Insurgency: Sandstorm (didn't test anything else). Reboot didn't fix this either.
Replying to [#6051 (comment)](https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1207123916)
Hey glitch, thanks for your work, at the moment after installing the package you shared I'm getting this error when I try to boot games with EAC, tested with multiversus and elden ring: https://i.imgur.com/5s4Nnzs.png
Is there any way I can provide useful logs to you?Did you reboot after installing the package? I have seen similar issues for people that got fixed with a reboot. Also, don't use flatpacked steam client.
Yeah I did a reboot, I also did not use the flatpak, I don't have it installed either.
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1207208624
The fix isn't working for me either, I tried both the 'steam native' and steam with it's own libraries (I don't think this package actually comes with it's own glibc), neither one worked using the altered glibc/lib32-glibc packages.
Maybe it's the method I've installed those packages:
pacman -Qi glibc
gives the output:
Packager : Frederik Schwan <[email protected]>
Build Date : Sun Jul 31 13:47:41 2022
Install Date : Sat Aug 6 07:48:41 2022
Install Reason : Explicitly installed
Install Script : Yes
Validated By : Signature
The build date seems wrong?
Maybe it's the method I've installed those packages:
pacman -Qi glibcgives the output:Packager : Frederik Schwan <[email protected]>Build Date : Sun Jul 31 13:47:41 2022Install Date : Sat Aug 6 07:48:41 2022Install Reason : Explicitly installedInstall Script : YesValidated By : SignatureThe build date seems wrong?
seems like you haven't actually installed the custom glibc and are still using the original arch linux one
or maybe something else went wrong
I'll try installing it from the source code link
Just checked this, somehow installing via sudo pacman -U https://github.com/Frogging-Family/glibc-eac/releases/download/test/glibc-2.36-1-x86_64.pkg.tar.zst does not work, while downloading it and installing it via sudo pacman -U ~/Downloads/ glibc-2.36-1-x86_64.pkg.tar.zst does work.
Ok so I'm not going crazy, the package simply weren't updated on your ends :frog: That clears it up.
Ok so I'm not going crazy, the package simply weren't updated on your ends frog That clears it up.
I downloaded the package and installed it with pacman -U /file/location/here and then rebooted, but I got that different error I mentioned before.
Ok so I'm not going crazy, the package simply weren't updated on your ends frog That clears it up.
I downloaded the package and installed it with pacman -U /file/location/here and then rebooted, but I got that different error I mentioned before.
Your issue doesn't seem to be glibc related.
Edit: In case you're playing Star Citizen and blacklisting modules-cdn.eac-prod.on.epicgames.com in your /etc/hosts file, you might want to remove it before running your EAC game.
Ok so I'm not going crazy, the package simply weren't updated on your ends frog That clears it up.
I downloaded the package and installed it with pacman -U /file/location/here and then rebooted, but I got that different error I mentioned before.
Your issue doesn't seem to be glibc related. Edit: In case you're playing Star Citizen and blacklisting
modules-cdn.eac-prod.on.epicgames.comin your/etc/hostsfile, you might want to remove it before running your EAC game.
I tested with elden ring and multiversus.
You obviously know more than I do, so I'll trust you when you say it's not glibc related, it does seem odd to me though.
Before using your package I had the exact same error as in OP's picture.
After using yours I had a different one.
On the flip side, downgrading everything by editing /etc/pacman.conf to use older packages as a whole and downgrading, then that worked. And the issue didn't show up before I updated glibc (admittedly with other things too though)
Both of these games were tested by many users with success after that single commit revert offered in the packages I uploaded. That's why I find it especially weird that it would work for many (most?) and not for you. My OS is fully up to date as well and doesn't exhibit such an issue.
I guess you could give https://github.com/Frogging-Family/glibc-eac/releases/tag/test2 a try, as it was rebuilt against an up to date Arch (while the first test was built against a week or so old install with glibc 2.35).
We could check some proton logs out but considering the specifics of the issue and the closed nature of EAC, I'm not sure it'll be very helpful.
Nah worry not, I don't think it's particularly worth it if I'm such a small %
Not to mention that as you say it's likely something else, it just feels so weird to me, you can see where I'm coming from?
I guess we'll see when the issue is officially solved!
OK, also, as expected if downloading the precompiled binaries works, downloading the source linked above and running makepkg -si to build it from the PKGBUILD file works too. Though make sure to enable and install ccache.
It's long though... go for the binaries first.
I think it's just using the links rather than the downloaded files that results in it not working, for whatever reason pacman does something slightly different.
@DoubleAgentDave I have removed the ccache dependency so installing ccache isn't needed anymore 🙂
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1207113463
This looks like something that should be fixed by Epic rather than the glibc developers tbh
I can confirm elden ring & back 4 blood are working also. I had to install both the glibc and lib32-glibc patched libraries though.
wget https://github.com/Frogging-Family/glibc-eac/releases/download/test/lib32-glibc-2.36-1-x86_64.pkg.tar.zst
wget https://github.com/Frogging-Family/glibc-eac/releases/download/test/glibc-2.36-1-x86_64.pkg.tar.zst
sudo pacman -U glibc-2.36-1-x86_64.pkg.tar.zst lib32-glibc-2.36-1-x86_64.pkg.tar.zst
can anyone add this package to AUR for easy-to-use noob like me ?
It's not up to me, but I think adding this to the AUR is a really bad idea, the package would have the same version numbering and name as the original so I've no idea what that would do to package managers like octopi and pamac. The instructions here are exactly what you need to do though, bung these lines in a terminal and you'll be good to go:
I can confirm elden ring & back 4 blood are working also. I had to install both the glibc and lib32-glibc patched libraries though.
wget https://github.com/Frogging-Family/glibc-eac/releases/download/test/lib32-glibc-2.36-1-x86_64.pkg.tar.zst wget https://github.com/Frogging-Family/glibc-eac/releases/download/test/glibc-2.36-1-x86_64.pkg.tar.zst sudo pacman -U glibc-2.36-1-x86_64.pkg.tar.zst lib32-glibc-2.36-1-x86_64.pkg.tar.zst
can anyone add this package to AUR for easy-to-use noob like me ?
You can just clone the repository and run makepkg like you would with an AUR package.
I can confirm elden ring & back 4 blood are working also. I had to install both the glibc and lib32-glibc patched libraries though.
wget https://github.com/Frogging-Family/glibc-eac/releases/download/test/lib32-glibc-2.36-1-x86_64.pkg.tar.zst wget https://github.com/Frogging-Family/glibc-eac/releases/download/test/glibc-2.36-1-x86_64.pkg.tar.zst sudo pacman -U glibc-2.36-1-x86_64.pkg.tar.zst lib32-glibc-2.36-1-x86_64.pkg.tar.zst
Welp. I feel a bit dumb, but doing this fixed it for me too. I didn't realize I was supposed to download and install TWO packages rather than just one.
Thank you!
Hmm, didn't work for me, though my understanding is that the EAC in VRChat in particular is being especially difficult for people.
Hmm, didn't work for me, though my understanding is that the EAC in VRChat in particular is being especially difficult for people.
It seems to be broken for most people on the Steam Deck which is not using glibc 2.36, so the issue is different.
@Frogging101 thanks for the bisect! I've created a glibc bug for this.
https://sourceware.org/bugzilla/show_bug.cgi?id=29456
(I had to wait for the account to get created)
I can confirm elden ring & back 4 blood are working also. I had to install both the glibc and lib32-glibc patched libraries though.
wget https://github.com/Frogging-Family/glibc-eac/releases/download/test/lib32-glibc-2.36-1-x86_64.pkg.tar.zst wget https://github.com/Frogging-Family/glibc-eac/releases/download/test/glibc-2.36-1-x86_64.pkg.tar.zst sudo pacman -U glibc-2.36-1-x86_64.pkg.tar.zst lib32-glibc-2.36-1-x86_64.pkg.tar.zst
Installing these versions of the libraries breaks nscd/usermod functionality. Couldn't add user to any groups using these modified versions since it outputs a discerning nscd: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory. Rolling back fixed it.
Dunno if installing these is a safe idea atm.
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1208446124
if you don't think the precomiled ones are safe, just makepkg them from the github repo
I am pretty sure something on your system is messed up since tk-glitch is a well known person in the linux gaming community, and it seems to be working for everyone else
note: I haven't tried them yet, so maybe im wrong
Installing these versions of the libraries breaks nscd/usermod functionality. Couldn't add user to any groups using these modified versions since it outputs a discerning
nscd: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory. Rolling back fixed it. Dunno if installing these is a safe idea atm.
Just tested on my end and usermod and nscd are working just fine. That being said, I'm not signing those packages and depending on how you configured selinux, it might be an issue. Since it's not a default behavior on Arch, most users shouldn't have any problem with that.
The message is weird though.
https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1206888814 Bisect done:
Is the issue that Easy AntiCheat require that DT_HASH exist on glibc provided shared objects (e.g. libc.so.6)? In the GNU ABI, DT_HASH may not exist. DT_GNU_HASH is a strictly better replacement (both in performance and in size). Easy AntiCheat should drop the DT_HASH assumption and support DT_GNU_HASH (all OSABI values, including ELFOSABI_NONE).
if you don't think the precomiled ones are safe, just makepkg them from the github repo I am pretty sure something on your system is messed up since tk-glitch is a well known person in the linux gaming community, and it seems to be working for everyone else note: I haven't tried them yet, so maybe im wrong
I don't think they meant safe as in malicious. Just that it can break stuff.
nscd is broken on my system also
nscd: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory
edit: @Tk-Glitch btw, unless I have really forgotten something. I have never set up selinux on this system. I'm not quite sure that the error is all about.
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1208719971
Could you please try the CI build (in github actions)? The zip will contain both packages.
Could you please try the CI build (in github actions)? The zip will contain both packages.
What's the difference between the CI build and the one from the releases? The commit messages just look like a few docs changes.
edit: with the CI build, usermod and nscd appear to work again
Could you please try the CI build (in github actions)? The zip will contain both packages.
What's the difference between the CI build and the one from the releases? The commit messages just look like a few docs changes.
edit: with the CI build,
usermodandnscdappear to work again
The CI build was built against a fresh and clean environment, which wasn't really the case for the test packages (which were built against my dev environment, which, while pretty sane, might have selinux tooling in PATH :frog: ).
Thanks for confirming it works. I'll offer those packages instead so it should work for everyone.
I can confirm elden ring & back 4 blood are working also. I had to install both the glibc and lib32-glibc patched libraries though.
wget https://github.com/Frogging-Family/glibc-eac/releases/download/test/lib32-glibc-2.36-1-x86_64.pkg.tar.zst wget https://github.com/Frogging-Family/glibc-eac/releases/download/test/glibc-2.36-1-x86_64.pkg.tar.zst sudo pacman -U glibc-2.36-1-x86_64.pkg.tar.zst lib32-glibc-2.36-1-x86_64.pkg.tar.zst
I can also confirm this just worked for me on Manjaro, kernel 5.15.59-1. Elden Ring stopped working today after I installed all of the recent updates through the regular package manager.
@rob215x You will want to install the bins from this zip instead, as mentioned in the other comment. It looks like there are some links to libselinux that you probably don't want in the released build
https://github.com/Frogging-Family/glibc-eac/actions/runs/2820674546
@rob215x You will want to install the bins from this zip instead, as mentioned in the other comment. It looks like there are some links to
libselinuxthat you probably don't want in the released buildhttps://github.com/Frogging-Family/glibc-eac/actions/runs/2820674546
First, Thanks!!
Please forgive me if I sound like a noob, but I'm trying to convince my audience on social media that in 2022 you can finally replace your Windows desktop with Linux for gaming. Are there some updated commands that people can simply copy and paste into a terminal and fix their games?
Since I applied the first set of glibc patches, Elden Ring starts fine and works, but it does a tiny bit of stuttering, like I'm not getting the super smooth 60fps I normally get. Now this could be because I didn't restart yet, so I'm going to try than next. =)
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1208923196
Sadly, nope. This requires recompiling the package from source code, and then repackaging, which changes for different distros.
PD: The thing about gaming on Linux is that for now, there are 0 guarantees for anything really. If it works, be glad it does.
I have updated the release prebuilts (and pushed a new one) so everyone will get the CI build now. No more selinux issue.
hopefully one day glibc will stop breaking stuff just for the sake of doing it, their reasons about all those breaking changes are all weird, in the end normal users get broken systems because the lack of responsibility, by people that seem to enjoy to constantly destroy our linux distro's user space without knowing what they are doing.
this is not the first time glibc started breaking software that me and people around me use, last time it was MS teams, my sister couldn't use it on linux and i had to install an LTS distro that works poorly in her hardware
if real world software are using those functions why remove them?
i can't get the logic of such things inside my head, even if it's ugly or bad it was there and used to work!
hoping for a revert of all those breaking changes so we can go back to normal.
At present I would not make any changes to glibc. I would close bug 29456
as RESOLVED/WONTFIX. I'm open to hearing from the EPIC EAC developers
if they have a case to make about DT_HASH.
In summary:
- DT_GNU_HASH was added in 2006, and for the last 16 years has been the
modern standard on Linux. The glibc change was made to allow the
distributions to choose how backwards compatible they want to be with
ELF consumers and the hash function and section. This is not ABI, just
like the PLT and RELRO are not ABI.
- One specific use case of "Easy Anti-Cheat" software is impacted by
this implementation detail change which impacts ELF consumers that
require DT_HASH.
- The choice to have DT_HASH is with the distributions. If this breaks
specific applications then those developers need to engage with the
ecosystem or adapt their software.
source: https://sourceware.org/pipermail/libc-alpha/2022-August/141304.html
well it seems like it's not really glibc's fault, they have made DT_GNU_HASH the standard and have made it standard for the past 16 years. I really think that this is epic's fault, for using an "API" that has been basically deprecated for 16 years.
The last gABI states that DT_HASH is mandatory [3], but DT_GNU_HASH works
a direct replacement meaning that it contains all information for symbol
resolution that DT_HASH provides.
Correct.
It was done as size optimization from perceived unused features since
DT_GNU_HASH is being used as a default on most distros for a long time,
meaning DT_HASH might not be set. For instance, on a Ubuntu 22.05 system
(GLIBC 2.35) only the glibc provided binaries (pldd, gencat, etc.) and some
external tools (nvidia command line) do provide DT_HASH.
at least it is easy to fix, since it appears to be a drop in replacement
Please forgive me if I sound like a noob, but I'm trying to convince my audience on social media that in 2022 you can finally replace your Windows desktop with Linux for gaming. Are there some updated commands that people can simply copy and paste into a terminal and fix their games?
Since I applied the first set of glibc patches, Elden Ring starts fine and works, but it does a tiny bit of stuttering, like I'm not getting the super smooth 60fps I normally get. Now this could be because I didn't restart yet, so I'm going to try than next. =)
Your stuttering likely has nothing to do with anything mentioned here. You may have issues with other binaries like usermod and nscd on the previous builds though,
These will clear up those potential issues:
wget https://github.com/Frogging-Family/glibc-eac/releases/download/release_1/glibc-2.36-1-x86_64.pkg.tar.zst
wget https://github.com/Frogging-Family/glibc-eac/releases/download/release_1/lib32-glibc-2.36-1-x86_64.pkg.tar.zst
sudo pacman -U glibc-2.36-1-x86_64.pkg.tar.zst lib32-glibc-2.36-1-x86_64.pkg.tar.zst
Just as a general note, you should be wary of copy-pasting random things from the internet and running them in your terminal.
Has someone opened a bug report with Arch Linux to resolve it there?
I'm thinking about possible solutions on our side. Though patching glibc without any upstream support is not going to be maintained for a long time. So when glibc decides to not revert the commit, it's up to Epic to fix the issue or to come up with a good reason to use these old headers.
I'm willing to cooperate with upstream and Epic here, but unfortunately I have no contact to Epic and can't find anything besides the obvious support channels.
/Arch Maintainer
Has someone opened a bug report with Arch Linux to resolve it there?
there is no point, the glibc package is working as expected and EAC should be using the correct DT_GNU_HASH, instead of DT_HASH
Epic Games has to fix this, not us
I am pretty sure something on your system is messed up since tk-glitch is a well known person in the linux gaming community, and it seems to be working for everyone else note: I haven't tried them yet, so maybe im wrong
For the record, kindly don't assume things about my system with a boiler-plate Microsoft Answers-level auto-response especially when you haven't even tried it yourself. I was simply talking in a manner of stability. If one thing in this thread is teaching us anything, is that even trusted sources can cause problems - which they've admitted themselves by updating the packages so they don't generate weird issues like that anymore (that I checked and can confirm).
Regardless, the situation surrounding upstream's response seems like stubborn Linux politics coming back to play.
On the one hand, using a deprecated function probably wasn't the best idea in Epic's case--especially being as well known as they are for not supporting the Linux ecosystem as well as they perhaps should.
On the other hand (and this is my inner normal player speaking here), most users wouldn't care about the why; all they know is that their thing doesn't work because an update happened that broke it, which feels pretty Windows-like. And if they're in this situation, they won't be able to fix it without something they might consider to be command line voodoo magic with files randomly downloaded off 'some dudes' repo (doesn't even matter if it's TkG's or some other maintainer's).
I would love to be wrong on this, sincerely, but I have my doubts Epic would care to fix this--let alone in a timely manner.
I am pretty sure something on your system is messed up since tk-glitch is a well known person in the linux gaming community, and it seems to be working for everyone else note: I haven't tried them yet, so maybe im wrong
For the record, kindly don't assume things about my system with a boiler-plate Microsoft Answers-level auto-response ~especially when you haven't even tried it yourself~. I was simply talking in a manner of stability. If one thing in this thread is teaching us anything, is that even trusted sources can cause problems - which they've admitted themselves by updating the packages so they don't generate weird issues like that anymore (that I checked and can confirm).
Sorry I didn't know what manner you were talking about, I thought you meant that they weren't safe packages to use (aka, they have malicious code), I didn't know that you meant it in the manner of stability.
I also tried the packages afterward and they worked fine, and I didn't edit the comment to reflect that
Sorry I didn't know what manner you were talking about, I thought you meant that they weren't safe packages to use (aka, they have malicious code), I didn't know that you meant it in the manner of stability. I also tried the packages afterward and they worked fine, and I didn't edit the comment to reflect that
This is maybe pedantic, but I wouldn't really call the packages "safe". That doesn't mean there is something malicious in them, it just means they are unsigned and from an "untrusted" third party. That said, I installed them and I am thankful for the free work donated by you folks to fix this issue.
Has someone opened a bug report with Arch Linux to resolve it there?
there is no point, the glibc package is working as expected and EAC should be using the correct DT_GNU_HASH, instead of DT_HASH Epic Games has to fix this, not us
Well, I guess the only way this going get rectified most likely through Valve when they decide to upgrade the Steam OS to a newer version glibc, But that can be far far out in the futrure...
Well, I guess the only way this going get rectified most likely through Valve when they decide to upgrade the Steam OS to a newer version glibc, But that can be far far out in the futrure...
Wasn't it mentioned that it's on the maintainer to maintain use of DT_HASH if they chose to? I imagine Valve would probably do that, since SteamOS (to my understanding) is already a curated selection of apps/utilities for the system.
In that case, it would be outside of Valve's payroll to bother if it 'only' affects main desktop Arch users (and whoever else decides to follow suit with upstream).
In that case, it would be outside of Valve's payroll to bother if it 'only' affects main desktop Arch users (and whoever else decides to follow suit with upstream).
Does this not affect steam deck users?
Shovel Knight is also broken by this, causes this error on a stack trace.
Using a patched build with DT_HASH restored fixes SK, so this breaks way more than just EAC
In that case, it would be outside of Valve's payroll to bother if it 'only' affects main desktop Arch users (and whoever else decides to follow suit with upstream).
Does this not affect steam deck users?
It does, but only for the future, ATM valve is using a VERY outdated arch repository for SteamOS Holo
at least it is easy to fix, since it appears to be a drop in replacement
If that's the case, would it be possible to forward all calls made to DT_HASH to DT_GNU_HASH? Not totally sure how this all works.
@Bitwolfies hi, thanks for looking into Shovel Knight. I've mention your finding in the glibc issue.
DT_HASH and DT_GNU_HASH are just sections in the binary. It's not something that's getting called. The software that understands ELF can then interpret the section and use it to get the count of the symbols and to speed up symbol lookup. See https://flapenguin.me/elf-dt-gnu-hash if you are interested in details.
So sadly no, if it's not in the .so we cannot really do anything to fix the software that parses ELFs and expects the section to be there.
@Frogging101 @Tk-Glitch
It looks like the changes in the problem commit are in the build scripts. Would it be enough to just add --hash-style=both to CFLAGS, CPPFLAGS, and LDFLAGS?
Also, are there any native Linux games using EAC that could be tested? I'm wondering if what's breaking is something in WINE/Proton. If so, then maybe WINE/Proton could be patched to work around the problem.
Please try glibc-2.36-2 in [testing]
Please try
glibc-2.36-2in[testing]
does it have the rogue company patches too or is it just the EAC ones?
does it have the rogue company patches too or is it just the EAC ones?
Just the latter.
Please try
glibc-2.36-2in[testing]
Tested with Eldering Ring. It seems to work. The tkg one doesn't.
I just received an update for glibc on EndeavourOS:
Package (19) Old Version New Version Net Change Download Size
core/glibc 2.36-1 2.36-2 0,08 MiB 9,87 MiB
core/lib32-glibc 2.36-1 2.36-2 0,05 MiB 3,38 MiB
I can confirm that EAC with 2.36-2 works again for the following F2P games on Steam: MultiVersus, Brawlhalla, POLYGON. Previously on 2.36-1, the games wouldn't even start.
I can confirm Multiversus with EAC, glibc 2.36-2 on arch.
can confirm but with a different error,
/data/games/steamapps/common/Apex Legends/EasyAntiCheat_launcher.exe: line 1: MZ����@��: not found
/data/games/steamapps/common/Apex Legends/EasyAntiCheat_launcher.exe: line 2: can't open �d-R�d-R�d-R�б��i-R�б���-R�б��y-R�6EQ�r-R�6EW�%-R�6EV�F-R�mU�u-R�d-S��-R�E[�t-R�E��e-R�d-ńe-R�EP�e-R�Richd-R�PEL{��]�
2�
˒P@@6�@�h����: no such file
/data/games/steamapps/common/Apex Legends/EasyAntiCheat_launcher.exe: line 2: .rdatavxPz6@@.datax%��@�.rsrc��: not found
/data/games/steamapps/common/Apex Legends/EasyAntiCheat_launcher.exe: line 3: �: not found
/data/games/steamapps/common/Apex Legends/EasyAntiCheat_launcher.exe: line 4: can't open �Y�j: no such file
/data/games/steamapps/common/Apex Legends/EasyAntiCheat_launcher.exe: line 6: ��V��F�lE�: not found
/data/games/steamapps/common/Apex Legends/EasyAntiCheat_launcher.exe: line 5: hX[F���F�u�h�?E��Y�j4��-E�rj^3�u�3�f�E�hTOF�M�}�薎�}��M�3�}�hTEF�u�f�E��z��E��E��u�=�FP�E�=�FP�=: not found
/data/games/steamapps/common/Apex Legends/EasyAntiCheat_launcher.exe: line 3: �p@��@p^Th_�^@P.text#02: not found
/data/games/steamapps/common/Apex Legends/EasyAntiCheat_launcher.exe: line 8: syntax error: unexpected ")"
EAC is literally being executed as a script.
^^ oops, Apex Legends was launching not under proton for some reason (unselected Force use of steam compatibility tool), though i was able to 'launch' the game
could it be that the people with glibc-2.36-2 using Arch is working due to this commit?:
https://github.com/archlinux/svntogit-packages/commit/e1d69d80d07494e3c086ee2c5458594d5261d2e4#diff-745744ee9938ff138304efac4d74053cf765db46a868614c325215b0512dce81
however, Apex is working for me without the aformentioned commit (glibc 2.36), but i am not on Arch.
I know that flatpak is an entire different (Github) issue, but technically it's the same (programmatically) issue.
Though is there an (Github) issue about this for the flatpak version I wonder?
Elden Ring not launching here too:
Manjaro Gnome on lastest Nvidia.
I have installed:
glibc 2.36-1
But don't have glibc 2.36-2
Elden Ring not launching here too: Manjaro Gnome on lastest Nvidia. I have installed: glibc 2.36-1 But don't have glibc 2.36-2
you can download it from the arch repos (probably not a good idea), or wait for manjaro to add it in
glibc 2.36-2 seems to work where 2.36-1 didn't, does this thread need closing now? Seems to be they explicitly edited the hash values that were altered in 2.36-1
[https://github.com/archlinux/svntogit-packages/commits/packages/glibc/trunk]
Besides it's not a bug in proton itself.
glibc 2.36-2 seems to work where 2.36-1 didn't, does this thread need closing now? Seems to be they explicitly edited the hash values that were altered in 2.36-1
[https://github.com/archlinux/svntogit-packages/commits/packages/glibc/trunk]
Arch Linux is not all distros and the core issue has not been resolved. glibc upstream hasn't changed and EAC hasn't changed.
Instead of closing i suggest to pinpoint the issue.
Reintroducing a deprecated code is just a temporary workaround, not a fix!
Mostly, not a workaround that can could be mantained forever.
The correct thing to do would be for Epic to rebase their code on the new hash. This is definitely an issue which Valve must take in its hands.
Instead of closing i suggest to pinpoint the issue. Reintroducing a deprecated code is just a temporary workaround, not a fix! Mostly, not a workaround that can could be mantained forever. The correct thing to do would be for Epic to rebase their code on the new hash. This is definitely an issue which Valve must take in its hands.
Even if epic fixes their code, that doesn't change this removal will break other games as i've proven with Shovel Knight. As much as it sucks there's tons of games and apps that will break and never update again. I just don't think its removal is worth it unless they can find a way to make an additional compatibility layer.
The Steam Runtime is a solution, but i'm unsure if Valve is actually able to maintain a patched version on their own, and per game patching it sounds time consuming. And if they are able to maintain a patched version, why not just open it to the community? And it also wont fix system apps.
Even if epic fixes their code, that doesn't change this removal will break other games as i've proven with Shovel Knight. As much as it sucks there's tons of games and apps that will break and never update again. I just don't think its removal is worth it unless they can find a way to make an additional compatibility layer.
Completely agreed. Linux has a backwards compatibility issue, where unmaintained native Linux games won't run anymore. The Linux gaming community has made it a point to get old Windows games to work, why do we need to break our games?
Unless there's a serious security implication, changes that break games and software should be discussed properly.
Instead of closing i suggest to pinpoint the issue. Reintroducing a deprecated code is just a temporary workaround, not a fix! Mostly, not a workaround that can could be mantained forever. The correct thing to do would be for Epic to rebase their code on the new hash. This is definitely an issue which Valve must take in its hands.
Unfortunately, this is a big issue with gaming. Unless the game is constantly getting updates for years, then this attitude will break games. Most games get their primary revenue in the first week to first month. If it's not getting DLC or if it's not a Service game, then many games won't get updated in the future.
Basically, if we want games working in Linux we either support "old features" for backwards compatibility or just accept that gaming is a lost cause on Linux.
I've had this argument with game devs in the past. From their standpoint, it's just not worth the cost/dev time needed to keep updating their games indefinitely to keep in line with system libraries and we won't be changing their minds anytime soon
While it would be nice for epic to rebase their code on this new hash (in fact they probably should), we still have to keep the old hash around for backwards compatibility
Blog post about the issue from ivyl if it is of interest.
https://blog.hiler.eu/win32-the-only-stable-abi/
For pacman distros users, I have modified Arch's glibc 2.36 PKGBUILD to include a revert for the commit Frogging101 bisected (thanks again !), which seems to be enough of a fix for EAC to work as it was on 2.35. Multiversus, Brawlhalla and Video Horror Society were tested successfully.
It also needed a couple changes to build (using system localedef and disabling two tests).
Here's the tree: https://github.com/Frogging-Family/glibc-eac And here are prebuilt packages: https://github.com/Frogging-Family/glibc-eac/releases (install with
sudo pacman -U packagename.pkg.tar.zst)
I confirm this is working for Elden Ring with Manjaro Gnome on Nvidia with GE-Proton 7.28.
Does not working with Proton Experimental. (It pass EAC and game stay in launched status, need to restart steam)
For pacman distros users, I have modified Arch's glibc 2.36 PKGBUILD to include a revert for the commit Frogging101 bisected (thanks again !), which seems to be enough of a fix for EAC to work as it was on 2.35. Multiversus, Brawlhalla and Video Horror Society were tested successfully.
It also needed a couple changes to build (using system localedef and disabling two tests).
Here's the tree: https://github.com/Frogging-Family/glibc-eac And here are prebuilt packages: https://github.com/Frogging-Family/glibc-eac/releases (install with
sudo pacman -U packagename.pkg.tar.zst)
Didn't work for me in New World but the other games i tried.
Blog post about the issue from ivyl if it is of interest. https://blog.hiler.eu/win32-the-only-stable-abi/
Forgive my noob question. It wouldn't be technically possible to add glibc to the Steam Linux Runtime?
Forgive my noob question. It wouldn't be technically possible to add glibc to the Steam Linux Runtime?
Not if you don't want to also ship the graphics drivers. To use the ones provided by the host you have to use host's glibc otherwise it's too likely that things will break on host update.
Forgive my noob question. It wouldn't be technically possible to add glibc to the Steam Linux Runtime?
Not if you don't want to also ship the graphics drivers. To use the ones provided by the host you have to use host's glibc otherwise it's too likely that things will break on host update.
And shipping the graphics drivers could be an issue for NV users.
Manjaro now got the glibc 2.36-2 update from Arch and EAC is working now with it.
https://forum.manjaro.org/t/stable-update-2022-08-16-glibc-with-eac-fix-nextcloud-kde-git-cinnamon-haskell-python/119481
the new arch glibc update (2.36-2) didnt work for me on Multiversus, anyone have any idea why?
I know that flatpak is an entire different (Github) issue, but technically it's the same (programmatically) issue. Though is there an (Github) issue about this for the flatpak version I wonder?
This is not an issue with the Flathub package because its runtime currently ships with glibc 2.33. The next version of the runtime, due this month or next, will be shipping with glibc 2.35, and we'll have that for a year or so after it ships. It's currently using default build options, and I've tested Multiversus working on the 22.08 beta. Users of the Flathub package won't have to worry about this for at least a year.
I was asking in the Flatpak channel on Matrix about changing the build defaults for 23.08, which is anticipated to ship glibc 2.37, but some of the maintainers are not clear on what the DT_HASH situation is going to be in future glibc releases. Is the support going to be removed completely, or will it remain a non-default build option?
the new arch glibc update (2.36-2) didnt work for me on Multiversus, anyone have any idea why?
I can confirm the latest update of Manjaro got glibc 2.36-2 and this DID NOT fix the problem , my games still crash (Apex Legends, No Man Sky, Elite Dangerous). From the command line output it seems to be the same exact outptut but I am not 100 % sure so dont quote me on this. But the crashes nonetheless happen exactly the same way as previously just a few seconds after launching the game, I get the intro screen and the boom crash.
the new arch glibc update (2.36-2) didnt work for me on Multiversus, anyone have any idea why?
I can confirm the latest update of Manjaro got glibc 2.36-2 and this DID NOT fix the problem , my games still crash (Apex Legends, No Man Sky, Elite Dangerous). From the command line output it seems to be the same exact outptut but I am not 100 % sure so dont quote me on this. But the crashes nonetheless happen exactly the same way as previously just a few seconds after launching the game, I get the intro screen and the boom crash.
the game isin't supposed to crash, it's only supposed to say "unable to load the anti cheat module", sounds like a different problem
the new arch glibc update (2.36-2) didnt work for me on Multiversus, anyone have any idea why?
In my crystalball, I see... we need logs.
the new arch glibc update (2.36-2) didnt work for me on Multiversus, anyone have any idea why?
I can confirm the latest update of Manjaro got glibc 2.36-2 and this DID NOT fix the problem , my games still crash (Apex Legends, No Man Sky, Elite Dangerous). From the command line output it seems to be the same exact outptut but I am not 100 % sure so dont quote me on this. But the crashes nonetheless happen exactly the same way as previously just a few seconds after launching the game, I get the intro screen and the boom crash.
the game isin't supposed to crash, it's only supposed to say "unable to load the anti cheat module", sounds like a different problem
Its not just a game, its multiple games crashing Apex Legends, Elite Dangerous and No Man Sky.
here is the full log from the command line when launching Apex Legends, it loads the entry screens displaying the respawn and EA log and animation and the as sson as it tries to load the main menu it crashes
The crash happens at line 133
I also tried flatpak steam, same problem , same crash
So maybe in my case it may not be glibc , however what I know for a fact is that the crashes started happening as soon as a manjaro update took place that included glibc too. Before that everything was playing fine. All games crash the same way , try to load their logo screens which usually they do and as soon they try to get to the main menu ui they crash.
I also manage to find a log file for EAC in comdata , in AppData/Roaming/EasyAnticheat/gamelauncher.log and it reports that it loads succesfully
[Info] Desktop screen settings detected. DPI: 96 DPI Multiplier: 1.000000 BPP: 32.
[Info] Localization loaded for: 'en-US'.
[Info] Settings file full path: 'Z:\home\kilon\.local\share\Steam\steamapps\common\Apex Legends\EasyAntiCheat\Launcher\Settings.json'.
[Info] Start. ExecutablePath: 'Z:\home\kilon\.local\share\Steam\steamapps\common\Apex Legends\R5Apex.exe' LaunchParameters: '-steam -eac_executablename "R5Apex.exe"' WorkingDirectory: ''.
[Info] Finished window initialization.
[Info] [LauncherProgress] 0%.
[Info] [LauncherProgress] 0%.
[Info] [LauncherFinished] EACAsyncResult: 0 Message: 'Easy Anti-Cheat successfully loaded in-game'.
[Info] Unloading the EasyAntiCheat library.
[Info] Destroying windows.
[Info] Exit.
PS: No Man Sky crash log
https://pastebin.com/E5NqEykP
If this is not related to this issue, I can open a separate issue
Here is also the proton log
https://gist.github.com/kilon/042d7f8870676da73eec29ede0560bc9
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1220699880
This sounds like a different issue, flatpak uses glibc 2.33 and is completely sandboxed with completely different mesa drivers and shared libraries, if both (flatpak and native) are not letting you reach in game then it's definitely a different issue
Elden Ring works for me when I run Proton 7.0-4 instead of experimental or GE. Online works. It may just be my setup though. I'm on Arch with glibc 2.36-2.
Elden Ring works for me when I run Proton 7.0-4 instead of experimental or GE. Online works. It may just be my setup though. I'm on Arch with glibc 2.36-2.
Arch Linux glibc 2.36-2 has reverts meant to fix EAC, upstream is still broken
The alpha of Fedora 37 also have this problem and they have 2.36-2 on it. It's fine on Fedora 36
The alpha of Fedora 37 also have this problem and they have 2.36-2 on it. It's fine on Fedora 36
The "-2" is a downstream version and hence has no meaning across distributions. You should report the problem to your Linux distribution Fedora instead.
It seems Fedora mantainers are aware and don't care at all though. If you like Fedora i suggest you to switch to Nobara.
OpenMandriva was affected, and has released an updated glibc 2.36 package that brings back DT_HASH to make EAC happy.
It seems Fedora mantainers are aware and don't care at all though. If you like Fedora i suggest you to switch to Nobara.
Could you link the Fedora bug?
It seems Fedora mantainers are aware and don't care at all though. If you like Fedora i suggest you to switch to Nobara.
Could you link the Fedora bug?
What bug?
What bug?
Whatever you got the impression that Fedora maintainers are aware but don't care from. I assumed it would have been a bug report.
What bug?
Whatever you got the impression that Fedora maintainers are aware but don't care from. I assumed it would have been a bug report.
That's not a bug. It is an upstream change, where a long deprecated feature has been removed.
Glibc devs don't consider it a regression and Fedora mantainers neither. So that's why i suggested to switch to Nobara, which is essentially a Fedora distro focused on gamers.
In Nobara it has already been patched.
I just think they meant if there was a issue report they could be linked to. Like a bug tracker or what ever they use.
I believe you can read this message thread. Not sure on the status, but it seems to be actually in the work for F37+. In the early replies it didn't seem like it would happen. This the latest status I know of, from last week.
https://www.mail-archive.com/[email protected]/msg183704.html
AFAIK, Fedora releases minor updates to Glibc during the release cycle. So if they will not enable DT_HASH for Fedora 37 before GA, does that mean they will be able to enable it after GA?
There's nothing to be "fixed" on Glibc's or Fedora's part. The symbol has been deprecated for 16 years, but Epic didn't care.
It's not even a public API or ABI call. Epic didn't care.
On top of that, Epic decided for some stupid reason to use their own methods for symbol lookup.
I beg that you read Carlos's summary. DT_HASH is a protocol between a linker and a dynamic loader. It is not intended to be consumed by a random non-standard ELF consumer. In addition, 16 years have been sufficiently long for any non-standard ELF consumer to know that DT_HASH has been mostly eliminated from Linux distributions. The glibc change removed one remnant DT_HASH use. It really was not as impactful as other changes in glibc 2.36.
And now everyone's pointing fingers at Glibc and Fedora. Why? Epic caused this, so ask them to fix it. You write code that relies on the internals? Fine, but then YOU fix your sh*t when internal things change.
All Epic has to do with EAC is
sed -i s/DT_HASH/DT_GNU_HASH/g *
make clean
make
/thread
I'm not commenting on what's considered public ABI or not here, just to correct a factual mistake:
All Epic has to do with EAC is
sed -i s/DT_HASH/DT_GNU_HASH/g * make clean make
No, DT_HASH and DT_GNU_HASH have different formats. It's the changes to the underlying hash table format that make DT_GNU_HASH technically superior.
There's nothing to be "fixed" on Glibc's or Fedora's part. The symbol has been deprecated for 16 years, but Epic didn't care.
It's not even a public API or ABI call. Epic didn't care.
On top of that, Epic decided for some stupid reason to use their own methods for symbol lookup.
I beg that you read Carlos's summary. DT_HASH is a protocol between a linker and a dynamic loader. It is not intended to be consumed by a random non-standard ELF consumer. In addition, 16 years have been sufficiently long for any non-standard ELF consumer to know that DT_HASH has been mostly eliminated from Linux distributions. The glibc change removed one remnant DT_HASH use. It really was not as impactful as other changes in glibc 2.36.
It is worth noting that DT_HASH is documented in the System V ABI for presumably over 16 years
DT_GNU_HASH, however, was only documented this year according to the link you posted
Regardless of the need for writing your own symbol lookup (of which Epic wasn't the only game company to do this), picking the documented ABI over a what was probably not documented at the time the code was written, does at a glance seems somewhat logical.
Aren't there other games and software that use DT_HASH? Isn't (or wasn't) for example Spiral Knight broken?
Edit: Shovel Knight, thanks Bitwolfies.
Aren't there other games and software that use DT_HASH? Isn't (or wasn't) for example Spiral Knight broken?
Shovel Knight was broken by DT_HASH's removal for me, I reported it but no one ever confirmed to me if it was also broken to them, regardless, its what appeared in the debug. And now works with restored Glibc.
I wasn't using git bisect, I just picked a random commit, idk how you would use a git bisect with a pkg build
I just cloned a copy of glibc in another directory and used bisect in that copy, and copied the commit IDs it gave me to the PKGBUILD.
Glibc with DT_HASH patched back in is now on Fedora 37 and Fedora Rawhide!
Glibc with DT_HASH patched back in is now on Fedora 37 and Fedora Rawhide!
RedHat screws it up for everyone, then backtracks the change on their own distro. Makes no sense all around.
Glibc with DT_HASH patched back in is now on Fedora 37 and Fedora Rawhide!
RedHat screws it up for everyone, then backtracks the change on their own distro. Makes no sense all around.
Fedora is not controlled by Red Hat.
Fedora is not controlled by Red Hat.
It's not, it's just that the Fedora Project was only founded by Red Hat among others, Red Hat also maintains liability for the Fedora Project, and Red Hat employees only make up 35% of project contributors with named roles in the Fedora Project Council appointed by Red Hat. But Fedora and the Fedora Project are obviously not controlled by Red Hat.
Fedora is not controlled by Red Hat.
... Red Hat employees only make up 35% of project ...
The committer and reviewer of the glibc commit that screwed everything up are both from RedHat. The committer of the Fedora fix is also from RedHat. He is even one of the persons who was responsible for the problematic glibc commit.
They should have tested the change in their own distros (Fedora, RedHat, CENTOS, etc) before screwing it up for everyone else.
To fix this on gentoo, you can add the hash-sysv-compat use flag to the glibc use flags: https://packages.gentoo.org/useflags/hash-sysv-compat
@Nanotwerp I like how their comment says "This is temporary as applications move to supporting only DT_GNU_HASH." as if decade old games will be recompiled to meet the needs of glibc.
I switched to the flatpak version of steam (I even completely uninstalled the native package) and am still having this issue so even switching may not fix it. (on Garuda linux if it matters)
I switched to the flatpak version of steam (I even completely uninstalled the native package) and am still having this issue so even switching may not fix it. (on Garuda linux if it matters)
In that case you are experiencing a different issue. The Flatpak 22.08 runtime's version of glibc is older than 2.36.
Maybe native Linux games should be statically-linked against musl libc (designed for static-linking, unlike glibc) and all/most other dependencies to avoid this kind of problem. This could be made a condition for being hosted in the Steam library going forward.
Maybe native Linux games should be statically-linked against musl libc (designed for static-linking, unlike glibc) and all/most other dependencies to avoid this kind of problem. This could be made a condition for being hosted in the Steam library going forward.
This issue is about a problem that occurs specifically with anti-cheat software rather than games. Your point might be more useful posted on another issue? Though Epic, the company that (probably) compiled the anti-cheat software that broke in this case, hopefully might one day read this post though I guess.
Though Epic, the company that (probably) compiled the anti-cheat software that broke in this case
Epic didn't break it, glibc broke it. Libraries are not supposed to change their ABI from one minor version to the next. And it's fixed in glibc.
Though Epic, the company that (probably) compiled the anti-cheat software that broke in this case
Epic didn't break it, glibc broke it. Libraries are not supposed to change their ABI from one minor version to the next. And it's fixed in glibc.
Did it actually get fixed? Do you have a link?
@Newbytee The fix is to patch glibc to add the option that they never should have removed, like Arch Linux does: reenable_DT_HASH.patch.
EAC broken with new glibc (2.37 -> 2.38), hope it gets fixed soon.
@morialo3 which game or games in particular do you have issues with? And have you been able to confirm it's glibc specifically?
Edit: also which distro are you using?
Confirming that EAC is broken.
Elden Ring.
glibc (2.37 -> 2.38) on ArchLinux.
Looks like Arch has dropped --hash-style=both: https://bugs.archlinux.org/task/79292
I'm working on a fix.
Halo MCC is working find.(as it shipped with a newer version of easyanticheat_x64.so)
It look like that any game that use Proton EasyAntiCheat Runtime is also broken.
Please test glibc-2.38-2 from [core-testing]. If you don't know how to use that, you can also download the packages here:
https://archlinux.org/packages/core-testing/x86_64/glibc/download/
https://archlinux.org/packages/core-testing/x86_64/lib32-glibc/download/
Please report back if these work. Thanks!
Please test glibc-2.38-2 from
[core-testing]. If you don't know how to use that, you can also download the packages here: https://archlinux.org/packages/core-testing/x86_64/glibc/download/ https://archlinux.org/packages/core-testing/x86_64/lib32-glibc/download/Please report back if these work. Thanks!
That worked on endeavourOS, thanks!
Please test glibc-2.38-2 from
[core-testing]. If you don't know how to use that, you can also download the packages here: https://archlinux.org/packages/core-testing/x86_64/glibc/download/ https://archlinux.org/packages/core-testing/x86_64/lib32-glibc/download/Please report back if these work. Thanks!
This works for Elden ring, proton exprimental on Archlinux.
It's in core now. Just updated and tested Hunt Showdown and it's working now. Thank you @freswa !!.
@morialo3 which game or games in particular do you have issues with? And have you been able to confirm it's glibc specifically?
Edit: also which distro are you using?
- I was trying to launch "Elden Ring", and I have noticed this message "Failed to inirilize tje anti-cheat module", so since the only update I did contained
glibcthat was my assumption. - I'm on Arch Linux
- An update had been pushed for
glibcto (2.38-2) fixed my issue. I hope that fixes everyone issues.
Bit of a random question, but any of you played Armored Core VI with a non DT_HASH glibc? (in that brief period of time when Arch shipped a non DT_HASH glibc before it got re-applied)
We believe the version of EAC in that title does not require DT_HASH but would like a confirmation.
Bit of a random question, but any of you played Armored Core IV with a non DT_HASH glibc? (in that brief period of time when Arch shipped a non DT_HASH glibc before it got re-applied)
We believe the version of EAC in that title does not require DT_HASH but would like a confirmation.
do you mean Armored Core VI, IV is from 2006...
and VI hasn't released yet (according to steam)
Ah yes - nevermind my question then, I had not realized it had not shipped yet :)
got same issue after update glibc to 2.38
- Env: Archlinux
- Game which failed to load EAC: Squad , Insurgency:Sandstorm
got same issue after update glibc to
2.38
- Env: Archlinux
- Game which failed to load EAC: Squad
Did you find a way to fix it? I just tried to run Squad and had the same problem!
Archlinux
Just tested this with 2.39 and it has the same issue as 2.38 on Arch Linux
This is probably the commit in question: https://gitlab.archlinux.org/archlinux/packaging/packages/glibc/-/commit/83899c6e216ef04a56f16faaa19fcbf84bd0f799
This is probably the commit in question: https://gitlab.archlinux.org/archlinux/packaging/packages/glibc/-/commit/83899c6e216ef04a56f16faaa19fcbf84bd0f799
@freswa I can confirm that Insurgency: Sandstorm is not patched and is affected by this issue still.
I ran steam through flatpak and it works for me
Also Back 4 Blood is not patched either, issue still happens
Seems like unfortunately the maintainer won't entertain the idea of patching glibc anymore: https://gitlab.archlinux.org/archlinux/packaging/packages/glibc/-/issues/3
So looks like people would have to report the issue to the devs of Back 4 Blood, Insurgency: Sandstorm and Squad. Not sure if the devs of the first 2 titles are still around.
It would be great to maybe have a fork on the AUR that has DT_HASH support; I couldn't find one.
@GenocideStomper
For binary: https://github.com/Frogging-Family/glibc-eac
To build from source, add -Wl,--hash-style=both to LDFLAGS in makepkg.conf, then build from https://gitlab.archlinux.org/archlinux/packaging/packages/glibc
"If it's a bug that people rely on, it's not a bug, it's a feature." -- Linus Torvalds
Here's an AUR repo for those looking for it: https://aur.archlinux.org/packages/glibc-eac
Tested with Insurgency: Sandstorm
Remaining affected games at the time of writing:
Back 4 Blood- Updated in 2024-05-15Brawlhalla- Updated in 2024-03-20 (???, note added in 2024-08-27, seems to work and last EAC update I can find is from this Patch, so presumably it worked for the last couple months)- Insurgency: Sandstorm
Squad- Updated in 2024-06-14- Squad 44 - last
EasyAntiCheat_Setup.exeupdate seems to be from 2019-11.
Writeup explaining why this happens (heavily technical)
Solutions
A) Use Flatpak - [Recommended] - EDIT[2024-11-02]: Looks like even Flatpak now dropped the extra patch, go nag the developers and publishers of the remaining two games.
B) Patch system glibc - not advisable, but possible, see comments above
C) Wait for the Publisher to decide to update their EAC build - They've had almost 2 years to do so at this point
Flatpak
In the case of Linux distributions (and Windows too), there is no inherent application sandboxing.
So both from a security[^3] and a convenience standpoint, running Steam in Flatpak (in a Wayland session)[^1] is the best[^4] option.
Flatpak's glibc still carries the extra patch for DT_HASH, and is overall a better solution than trying to patch system libraries to be able to run out of date versions of EAC for one or two games.
See historical examples with CoD RCEs, Souls games RCEs, RCEs directly in the Steam client which compromised the entire system by sending a single message, and other fun exploits, to see why lack of any sandboxing is a problem you might want to care about.
It is especially problematic in online games.
Were you to be affected by an RCE under the above-suggested setup, worst thing that would get compromised[^2] is all the files Steam has access to, instead of all the files you have access to on your entire operating system across all of your storage drives.
There is a small setup caveat on Nvidia[^5].
Fixing this upstream
Out of the above mentioned, only Back 4 Blood is an abandoned game (last update more than a year ago), rest is actively updated in the Steam depots.
If you are affected, open the linked Steam page, locate the contact information in the Support section, and let the Publisher and Developer companies know they need to update their game to keep it playable. Include a link to this thread.
They must already know, but they likely need to have enough people affected by it before they can assign developer time to the issue.
If you're going to do this, be nice and civil, there's a person on the other side.
Disclaimer
It is not my intention to start a "Flatpak vs Native" or a "Wayland vs X" flamewar, so if you've read this and got the idea to start arguing how Wayland/Flatpak is terrible because the software/hardware you use doesn't support it, or how you can't afford to spare extra storage/performance for Flatpak, you can safely skip responding to this post, it is only aimed at providing information about security and the current state of things.
[^1]: X is inherently insecure, so attempting to sandbox Steam with Flatpak, even though it will work and the added sandboxing is better than nothing, it will fail to produce a secure environment. On top of that, there are multiple security issues found relatively frequently that affect both X and XWayland (Wayland compat with X layer).
WINE is focused on adding support for Wayland, so it will hopefully be possible to get rid of XWayland in the future for all Windows games on a Wayland setup.
[^2]: Assuming no other additional sandbox-escape exploit 0-days.
[^3]: Flatpak isn't an inherently secure sandbox, it depends on the application's Flatpak manifest.
The manifest for Steam is doing a decent job, provided the OS' GUI session is not using Xorg.
[^4]: Flatpak has a cost in terms of storage taken, and the seccomp filter it uses for sandboxing might have a small performance cost, depending on the game, see this issue.
[^5]: On Nvidia, Flatpak requires an Nvidia driver matching the system driver. flatpak update should install the correct one for your system without further prompting.
It needs to be ran every time after updating to a newer Nvidia driver version(on the following reboot) and restarting the Steam app if it were running already using the wrong version, otherwise the performance will be terrible and games either won't launch at all or with terrible performance.
Solutions A) Use Flatpak - [Recommended] B) Patch system glibc - not advisable, but possible, see comments above C)
Flatpak has heavy performance penalty and isn't ideal for gaming for several reasons. It is broken for now, for several different reasons. Citing security considerations, without advertising it's flaws, is a disservice to the users, who may stumble upon them.
Flatpak should only be recommended, when users are aware that it will break their games and lower their framerate
- https://github.com/flatpak/flatpak/issues/4187
- https://github.com/flathub/com.valvesoftware.Steam/issues/770
On the matter of packagers decision to break EAC for Squad and several other games, citing original ticket https://sourceware.org/bugzilla/show_bug.cgi?id=29456
I'm marking this issue as RESOLVED WONTFIX, because the glibc build will include both hashes if that's how the distribution builds the ELF . It is up to the distributions to decide how to proceed with the availability of the hashes. There is no intent to fix this in glibc by forcing both hashes.
> It is up to the distributions to decide how to proceed with the availability of the hashes
While decision to break binary compatability on the GLIBC side is undoubtedly very stupid and their desire to fragment Linux distributions isn't ideal too and all the blame for this mess is on them, but.
There is no additional maintenance cost on the packaging side to maintain one additional flag.
Honestly, I don't see any justifications on reverting that patch, it's the recommended approach to fix this problem, by the people who created it (glibc developers).
Flatpak's glibc still carries the extra patch for DT_HASH, and is overall a better solution than trying to patch system libraries to be able to run out of date versions of EAC for one or two games.
Flatpak's glibc doesn't and never carried such patch. In 2022 flatpak's glibc was just older than version that broke EAC. For past half year flatpak's glibc version is new enough to be affected. If people didn't notice then maybe the issue is gone?
st half year flatpak's glibc version is new enough to be affected. If people didn't notice then maybe the iss
I still have the issue but I've glibc 2.39+r52+gf8e4623421-1
ming. Bloodhunt EAC breaks with glibc 2.36
I'm so sad!
I have opened a steam discussion on insurgency sandstorm as I saw the devs themselves respond there, letting them know that they need to update their EAC.
This was a huge shame, they release a new update for the game you would expect for the EAC to be updated, but no unfortunately it isn't.
https://steamcommunity.com/app/581320/discussions/0/4354498956230747468/
https://www.reddit.com/r/linux_gaming/s/SHEKOSRRLo
Can confirm, that Squad devs indeed fixed their issue
Someone just pinged me that Brawlhalla works, at least on proton experimental, and tracking down the patches, it seems they silently updated the EAC installer back in 2024 March, updated my post above.
This makes Insurgency: Sandstorm win the award of shame as it seems to be the last game that's broken.
Award of shame also goes to Squad 44
-------- Original Message --------
On 8/27/24 21:33, Martin wrote:
Someone just pinged me that Brawlhalla works on at least proton experimental, and tracking down the patches, it seems they silently updated the EAC installer back in 2024 March, updated my post above.
This makes Insurgency: Sandstorm win the award of shame as it seems to be the last game that's broken.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>
Award of shame also goes to Squad 44
Oh, that was not on my original list, looks like last EasyAntiCheat_Setup.exe update is from 2019, so that'd probably do it, did you contact the developer about it?
Maybe it's the method I've installed those packages:
pacman -Qi glibcgives the output:Packager : Frederik Schwan <[email protected]>Build Date : Sun Jul 31 13:47:41 2022Install Date : Sat Aug 6 07:48:41 2022Install Reason : Explicitly installedInstall Script : YesValidated By : SignatureThe build date seems wrong?seems like you haven't actually installed the custom glibc and are still using the original arch linux one or maybe something else went wrong
How do I even replace the system glibc with the patched one? Installing with yay or building manually causes a conflict and removing glibc to install the patch breaks the system forcing me to pacstrap it again
Replying to https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-2452815554
pkgctl clone official repo glibc, add the patch to the PKGBUILD yourself, do not change the pkgrel, build it, install it.
That way, when Arch updates glibc, your glibc will be correctly overwritten and your patch gone, until you update the pkgbuild against upstream and rebuild again, but at least it won't break your entire system every time.
Don't forget to message the developer and publisher everywhere you can before you do this, so they actually update their EAC build in the game.
I’m having an issue with Dead by Daylight and EAC, but I’m not seeing anyone else here mention DbD. Anyone know if DbD is using an old EAC too (or how I can find out) before I write them about it?
This is a pretty old issue, so any game that wasn't already here probably
never had a problem.
You can also check ProtonDB and see if anyone complains about it there.
DBD is pretty popular, so I doubt it's the same issue.
You can check depots to see when EAC was last updated, see my post above
with links, I think I link the Brawlhalla depo there
On Mon, Nov 11, 2024, 09:17 Frederik “Freso” S. Olesen <
@.***> wrote:
I’m having an issue with Dead by Daylight and EAC, but I’m not seeing
anyone else here mention DbD. Anyone know if DbD is using an old EAC too
(or how I can find out) before I write them about it?—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-2467499808,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAMQXEWBXZPBFEQZJQVKN6T2ABRYDAVCNFSM55NUV2P2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TENBWG42DSOJYGA4A
.
You are receiving this because you commented.Message ID:
@.***>
I come here to inform EAC is working with GLIBC 2.43 vanilla, also it work on Slackware doing a tweak.
EAC have been updated to not include any other patch to work.
Since GLIBC 2.34 the devs have changed how the libraries are been deploy.
I changed from:
/lib64/ld-linux-x86-64-2.43.soto/lib64/ld-linux-x86-64.so.2/lib64/libc-2.43.soto/lib64/libc.so.6
On Slackware Linux, it still ships with the old format, to remain the same format as the others libraries, using symlink on /lib64/libc.so.6 and /lib64/ld-linux-x86-64.so.2, but EAC don't like that, copy pasting the file over the symlink resolved the issue, but is just a workaround, since I cann't let the library stay like that, else it break the package manager when it try to removed/upgraded because it will try to unlink the file instead of deleting it.
I have uploaded a video on YouTube
https://youtu.be/uGNXfZdh3-Q?si=MLZ7DKsx-XQHuZ10
Alter the code to you current GLIBC
cd /lib64
cp -a libc-2.43.so libc.so.6.new && mv -f libc.so.6.new libc.so.6
cp -a ld-linux-x86-64-2.43.so ld-linux-x86-64.so.2.new && mv -f ld-linux-x86-64.so.2.new ld-linux-x86-64.so.2
# Launch the game
# Revert after you done with playing.
cd /lib64 # in case you have closed the terminal
ln -sf ld-linux-x86-64-2.43.so ld-linux-x86-64.so.2
ln -sf libc-2.43.so libc.so.6
PS: Slackware don't have mostly hardening enabled.
Proton versions
proton experimentalx3 2024-08proton 7.0-4x2 2022-08proton 7.28x1 2022-08
Titles With Problems:
Most titles that use Easy AntiCheat and officially support Linux
tested ( Multiversus, Elden Ring,
Apex Legends [mixed results])Error Description:
Launch Error: Failed to load the anti-cheat module
To recreate:
Be running the newest GLIBC in this case 2.36
Have Steam (not flatpak vers.)
Hardware: happens on both nvidia and amd systems
Sorry if this isn't the correct place to report the error, but I figured this team helped create the EAC module, so you would be the ones to contact.