From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 071823858C56; Fri, 12 Aug 2022 13:17:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 071823858C56 From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug build/29456] missing DT_HASH section in shared objects Date: Fri, 12 Aug 2022 13:17:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: build X-Bugzilla-Version: 2.36 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2022 13:17:58 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29456 --- Comment #14 from Adhemerval Zanella --- (In reply to Arkadiusz Hiler from comment #13) > > Does it also prevent us to add another possible HASH scheme in the futu= re, taking that EAC might break if it does see a DT_GNU_HASH? >=20 > 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. >=20 >=20 >=20 > There were two more breakages caused by dropping DT_HASH: >=20 > A native game - Shovel Knight: > https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-12127483= 97 >=20 > 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 s= eems that other mantainers seem reasonable to make DT_HASH optional if DT_GNU_HA= SH 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 discuss= ion to add a new dynamic section type [3]. > Shifting responsibility on downstream to maintain compatibility with som= ething > 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.=20 So I tend to agree that if DT_HASH compatibility is really required, it wou= ld be better to provide it as the default static linker option used to build g= libc (so you also ensure that all installed shared object does have it) as Gento= o 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 --=20 You are receiving this mail because: You are on the CC list for the bug.=