> On 1 Oct 2022, at 08:40, Fangrui Song via Libc-alpha wrote: > > On 2022-09-30, Carlos O'Donell via Libc-alpha wrote: >> On 8/9/22 05:21, Florian Weimer wrote: >>> * Carlos O'Donell via Libc-alpha: >>> >>>>> So the question is whether we should enforce at least on glibc by reverting >>>>> e47de5cb2d4dbec. It does sounds muddle to keep this solely on glibc, where >>>>> rest of the system is not enforcing it, and only for compatibility with an >>>>> obscure tools where there is no much information on why it requires it. >>>> >>>> The tool is EAC. >>>> >>>> It is EPICs "Easy Anti-Cheat" (https://www.easy.ac/en-us/) and like >>>> other non-standard consumers it has to know some specific ELF details. >>>> >>>> The game "Rogue Company" is known to use EAC and is likely broken by >>>> this change. >>> >>> I think there are several other glibc patches required to fix Rogue >>> Company? >>> >>> (“glibc with reverts >>> applied to allow Rogue Company to work with EasyAntiCheat”) makes the >>> following changes: >>> >>> · Install shared objects under traditional versioned nmaes. >>> · Bring back various GLIBC_PRIVATE symbols. >>> · Disable clone3. >>> >>> If EasyAntiCheat has been fixed for those, surely it can be fixed to use >>> DT_GNU_HASH as well. >> >> The fix is available in version 1.15.2 of the EOS SDK and in the new >> corresponding version of the anti-cheat module. This was released in August. >> >> Fixing this issue though requires several steps that need to be taken by the >> developers of the game itself. >> >> The issue therefore has direct impact on users of these binaries, and we can >> help lessen that impact by adding back DT_HASH. Making this change upstream >> has value for all the distributions that want to support these games. >> >> I am evaluating this change in isolation and weighing the pros and cons of >> just this change. As you note there are other changes impact other games and >> this speaks to me of a disconnect with how Linux is developed versus how these >> specific applications are being developed. That's something we can work on >> together as a community by engaging developers directly to see how their >> workflow maps to our update process. >> >> Looking across the distributions some of them are carrying a revert that adds >> back DT_HASH. Therefore I think it would help the distributions and add >> back DT_HASH support for a longer period of time before final removal. >> >> I don't think this will solve all the problems, but I will work to test out >> the revert on my Fedora system. > > Just a weak opinion: if downstream Linux distributions have done the > work to carry a local revert, reverting DT_HASH removal in the glibc > release branch doesn't seem to help them... True, but it helps those who have been on the fence and didn't want to deviate from glibc upstream. It also shows that it's an acceptable move to make. Best, sam