From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C06633858439; Mon, 8 Aug 2022 14:34:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C06633858439 From: "arek at hiler dot eu" To: glibc-bugs@sourceware.org Subject: [Bug build/29456] missing DT_HASH section in shared objects Date: Mon, 08 Aug 2022 14:34:37 +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: arek at hiler dot eu 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: Mon, 08 Aug 2022 14:34:37 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29456 --- Comment #5 from Arkadiusz Hiler --- (In reply to Florian Weimer from comment #3) > Distributions configure or patch GCC to pass --hash-style=3Dgnu to the li= nker > by default. The linker default does not matter. Thanks, that explains a few things. My gcc -v indeed claims that: Configured with: /build/gcc/src/gcc/configure ... --with-linker-hash-style=3Dgnu ... According to gcc/docs/install.texi the default is sysv but after browsing the code for a bit it looks like if `--with-linker-hash-style` is not specified no `--hash-style` is passed to the linker so it would depend on linker's defaults. Do you know why distros do this? Looking at package history it seems like an artifact from the times where both was a bit problematic. There used to be some custom patches for that years ago. (In reply to Adhemerval Zanella from comment #4) > > This breaks all the games running via Proton that are using EAC. >=20 > What EAC is doing exactly that requires a DT_HASH on glibc? What happens = if > you mix DT_HASH and DT_GNU_HASH shared objects (for instance shared > libraries with only one option)? It does seem a shortcoming from EAC, > although I am not sure what exactly it is trying to enforce here. I can only guess but probably to look up some symbols in multiple ways to assure no hooking has occurred. It seems to require it only for the glibc DSOs as they were shipping with DT_HASH for years, even on distros that default to gnu, and this is an unexpected change. --=20 You are receiving this mail because: You are on the CC list for the bug.=