Neal Gompa wrote: > There's a pretty decent write-up about this on LWN: > https://lwn.net/Articles/904892/ Here's a link that actually works: https://lwn.net/SubscriberLink/904892/dba951441b61cbdc/ (Putting the title and "SubscriberLink", both between quotes, into a search engine does wonders.)

It seems that upstream glibc disabled support for generating DT_HASH tables for its libraries and binaries, which breaks Linux games that use Epic Games' Easy Anti-Cheat (EAC).

Can we turn this back on for Fedora glibc until we can get Epic to make fixes for this and roll them out?

> It's Epic's fault. They must update their anti-cheat to use the modern > API. More reports have come out claiming this also affects the game Shovel Knight[2] and the open source library libstrangle[3], there is the non 0 chance that there are more programs out there in the wild that this will break. It feels irresponsible of the glibc maintainers to suddenly respect the toolchains desired hash type when they haven't for years and then do it with little to no announcement resulting in broken software

On 8/21/22 12:44, Jakub Jelinek wrote: > On Sun, Aug 21, 2022 at 12:05:11PM +0200, Jan Drögehoff wrote: >>> It's Epic's fault. They must update their anti-cheat to use the modern >>> API. >> More reports have come out claiming this also affects the game Shovel >> Knight[2] and the open source library libstrangle[3], there is the non 0 >> chance that there are more programs out there in the wild that this will >> break. >> >> It feels irresponsible of the glibc maintainers to suddenly respect the >> toolchains desired hash type when they haven't for years and then do it with >> little to no announcement resulting in broken software > To be precise, everything in Fedora except glibc is only built with > DT_GNU_HASH and no DT_HASH since July 2006, glibc has been an exception > that has been built with both because of statically linked programs from 16+ > years ago that wouldn't support it. I think its worth putting an emphasis on the fact that this was glibc intentionally ignoring the toolchain hash type and simply going with both and not something Fedora explicitly decided to do. > If all they want is be able to interpose dlsym, they could just use > dlvsym to look up the original sym, instead of diving into the hash tables. I do not think the change on glibcs part is bad, the hack was terrible to begin with but removing it broke the ABI and the lack of any announcement of it beforehand is now causing problems that distro maintainers and software developers have to deal with

> it's clear there's a documentation problem [with DT_GNU_HASH] Partly due to lack of documentation, already I have seen "abuses" of the DT_GNU_HASH format. In particular, some versions of Rust and/or musl run-times use (0 == nbucket) to mean something like "there is no hash table information" but do not specify all the implications for the run-time symbol table. Other versions use (1 == nbucket && 0 == buckets[0] && 1 == n_bitmask && 0 == bitmask[0]) for a similar purpose. Similarly, Rust and Android can trim "unused" zero entries from the end of &hash_array[nbucket], even though buckets[] and hash_array[] should be parallel.

> it's clear there's a documentation problem [with DT_GNU_HASH] Partly due to lack of documentation, already I have seen "abuses"

I don't disagree that glibc should respect what distros set, I'm just asking us to build glibc with a DT_HASH table added until a formal deprecation/retirement cycle is done with all stakeholders aware of the change and everyone aware of the consequences of such a breakage.

On Mon, 2022-08-22 at 08:43 +0200, Christoph Erhardt wrote: > Hi all, > > On Sunday, 21 August 2022 17:29:56 CEST Neal Gompa wrote: > > I don't disagree that glibc should respect what distros set, I'm > > just > > asking us to build glibc with a DT_HASH table added until a formal > > deprecation/retirement cycle is done with all stakeholders aware of > > the change and everyone aware of the consequences of such a > > breakage. > +1. Deprecations of this sort should follow a proper process with > sufficient > formal advance notice. +1. Such breakage will just harm the reputation Linux (IMO).

We are working on this and hope to have an update soon.

On 14/09/2022 05:27, Neal Gompa wrote: > Well, we just released the Beta and people have noticed that this is > still broken. Do we have an ETA on a fix? Because this is going to be > a major black eye for*us* if it stays broken through to GA. Epic Games had more than a month to fix the problem but they did nothing.

On Tue, Sep 13, 2022 at 11:27 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote: > > On Tue, Aug 23, 2022 at 4:13 AM Florian Weimer <fweimer(a)redhat.com&gt; wrote: > > > > We are working on this and hope to have an update soon. > > > > Well, we just released the Beta and people have noticed that this is > still broken. Do we have an ETA on a fix? Because this is going to be > a major black eye for *us* if it stays broken through to GA. > We're nearing the start of Final Freeze and nothing has materialized. Thus, I've filed a bug[1] and requested it to be declared a FESCo blocker[2]. I've also submitted pull requests to resolve the issue for F37[3] and Rawhide[4]. [1]: https://bugzilla.redhat.com/2129358 [2]: https://pagure.io/fesco/issue/2873 [3]: https://src.fedoraproject.org/rpms/glibc/pull-request/65 [4]: https://src.fedoraproject.org/rpms/glibc/pull-request/64