[Bug build/29456] missing DT_HASH section in shared objects

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29456

--- Comment #14 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Arkadiusz Hiler from comment #13)
> > Does it also prevent us to add another possible HASH scheme in the future, taking that EAC might break if it does see a DT_GNU_HASH?
> 
> The breakage here is not related to having DT_GNU_HASH, it's related to
> missing DT_HASH. I don't see how this is relevant.
> 
> 
> 
> There were two more breakages caused by dropping DT_HASH:
> 
> A native game - Shovel Knight:
> https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1212748397
> 
> Framerate limiter for OpenGL - libstrangle:
> https://bugs.gentoo.org/863863

It is relevant because we are discussing if it is reasonable to GNU ABI ELF
extension to keep DT_HASH mandatory.  From generic ABI discussion [1], it seems
that other mantainers seem reasonable to make DT_HASH optional if DT_GNU_HASH
is present on GNU objects, although some are not confortable on making it
optional for generic ABI (which is not the case anyway).

As Carlos has summarized [2], DT_GNU_HASH is the *de facto* standard hash
scheme for GNU and it has been used on distro deployments for over 16 years.
The generic ABI discussion has raises some missing spots where DT_GNU_HASH does
not cover (the total symbol list size) which generates another gABI discussion
to add a new dynamic section type [3].

>  Shifting responsibility on downstream to maintain compatibility with something
> that glibc provided for years as the default and there are now users of it
> is not really feasible.

And it is already being done anyway [5], since for such cases compatibility is
being done to revert upstream patches anyway instead of work on vendors to
adapt their code to a decade-old standard. 

So I tend to agree that if DT_HASH compatibility is really required, it would
be better to provide it as the default static linker option used to build glibc
(so you also ensure that all installed shared object does have it) as Gentoo is
doing [4].

[1] https://groups.google.com/g/generic-abi/c/th5919osPAQ
[2] https://sourceware.org/pipermail/libc-alpha/2022-August/141304.html
[3] https://groups.google.com/g/generic-abi/c/9L03yrxXPBc
[4] https://sourceware.org/pipermail/libc-alpha/2022-August/141312.html
[5] https://sourceware.org/pipermail/libc-alpha/2022-August/141313.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.