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