Should we make DT_HASH dynamic section for glibc?
Florian Weimer
fweimer@redhat.com
Tue Aug 9 09:21:21 GMT 2022
* 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?
<https://github.com/GloriousEggroll/glibc-eac-rc> (“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.
THanks,
Florian
More information about the Libc-alpha
mailing list