I'd say wait a few days to see if glibc-eac-bin gets updated. Could the name refer to easy anti cheat perhaps? The glibc is the official library that comes with Linux distros.
this post was submitted on 04 Aug 2024
24 points (92.9% liked)
Linux Gaming
15455 readers
26 users here now
Gaming on the GNU/Linux operating system.
Recommended news sources:
Related chat:
Related Communities:
Please be nice to other members. Anyone not being nice will be banned. Keep it fun, respectful and just be awesome to each other.
founded 4 years ago
MODERATORS
Yes, glibc-eac is a special version of glibc which supports steams new linux EAC "app", which is required for some/most eac games now, eg. Sea of thieves. I don't have issues using just glibc-eac - which is obviously the self compiled version - as far as I know (I didn't update in some days).
Do you mean you removed the non eac version of glibc?
I believe so. According to the PKGBUILD of glibc-eac, it not only conflicts with glibc (the package) but also provides glibc (the dependency for other packages), which means it's a drop-in replacement. Usually, the -bin version is exactly the same, just precompiled, so the same applies.
Btw, I forgot there was a bin version and I painstakingly compiled it every time, thanks for reminding me :3
Also: Don't forget to install glibc-eac-locales. Gave me headaches when I forgot it.
Ok so even though glibc is quite deeply integrated at the system level, its okay to replace it with the eac version(?). And what about the glibc-eac-locales? What are they for and why is it necessary to manually install them?
Yea, I learned my lesson about -bin packages a while ago with electron or something related to it. When I tell you it was taking several hours to compile and I was getting worried because while I dont have a supercomputer its on the high-end for an average user... xD I immediately grabbed the bin package right after that update finished.
glibc-eac is basically glibc, except with a few patches applied. Like literally just one additional .patch file. You can see that on the AUR listing, there is an additional patch called reenable DT, and the PKGBUILD applies this patch implying it's the only thing that needs to be changed. And indeed, the original PKGBUILD differs in just that one patch, afaik. They even have the same version number (as you can see with pacman -Q glibc-eac and pacman -Ss glibc). This means as long as the custom glibc-eac does not get out of sync too much, it's fine, as other packages usually don't rely on an exact version - it can't be guaranteed that the most recent version of something is installed all the time anyway.
As I see it, there's glibc and glibc-locales. And for some reason you need to install glibc-eac-locales instead of just glibc-locales when using glibc-eac - I guess it's because it's a split package, which means multiple packages are built with the same source.
On the same note, you'll also need the 32 bit version for steam things - basically just use the AUR manager of your choosing, search for glibc-eac and install everything that has a just-glibc equivalent already installed.
And on the topic of compiling: After installing LFS on a 14 yo Dell Latitude with Core 2 Duo (that thing could legally drink and fuck here in germany) I'm very patient and grateful for even my 5 2600 (6 cores). But it's a nice experience to compile stuff on my E5-2680 (14 cores). And I'm looking forward to the 9 9950x (16 cores) :3
It does not mean much if this is 1 patch file or 20. Any amount of changes can be packed in a single patch file. I think OP was rather interested in the security perspective: does the eac patched glibc reduce security in any way? If not, what does it change at all?
Personally I would assume it does, because otherwise why would there be a separate patched version, instead of including all the changes in the main glibc everyone uses?
As per the patch file:
[PATCH] force --hash-style=both to keep compatibility with old niche software
Per SO:
--hash-style allows you to change the format of hashtable which is used for runtime symbol resolution [...]. The GNU hashtable format is said to be slightly faster. [...] Both simply means that linked files will include, um, both gnu and sysv hashtables.
So it's just a patch to enable legacy stuff, with the potential drawback of slightly worse performance (which is given anyway in this case, because EAC bloat. Your usual software should be compatible with and therefore prefer the usual default of GNU hashtables, while EAC, that POS, will use the worser hashtable.)
Oh, thanks for looking it up. This sounds good and harmless.
Now it would be interesting to know if there's a legitimate need for this, or EAC just can't be bothered to fix their software.
I'm not that knowledgeable, but I guess it's EAC's fault: Apparently every application known to mankind, that uses glibc, is compatible with (the better) GNU hashtables. Except EAC. It may just be some incompatibility out of their reach, but then I wonder why every other program, native or run via wine, does not have this problem. My guess: They discovered that they could quietly remove GNU hashtable support, and therefore annoy most linux users, while just saying "your stuff is not compatible with my perfectly fine program".
Also: If it says "in conflict", and asks for user input, it means it will either replace the conflicting package, as the package you install provides the same things, or that it will only remove something you manually installed (I don't know if that's correct though). If it would remove a dependency of something else, without replacing that with something that provides the same, it would error out noting that there are unsolvable conflicts, as far as I know. That almost never happens though, as the whole pacman and AUR ecosystem are very well balanced, a bit less on testing repos.
I switched to flatpak steam because of this issue with a couple of games. Still annoyed that arch's glibc maintainer removed the eac patch.