From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <fw@deneb.enyo.de>
Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21])
	by sourceware.org (Postfix) with ESMTPS id 118043858D32
	for <libc-alpha@sourceware.org>; Sat,  1 Oct 2022 13:49:50 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 118043858D32
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=deneb.enyo.de
Received: from [172.17.203.2] (port=44827 helo=deneb.enyo.de)
	by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
	id 1oecs9-00Aasv-VO; Sat, 01 Oct 2022 13:49:41 +0000
Received: from fw by deneb.enyo.de with local (Exim 4.94.2)
	(envelope-from <fw@deneb.enyo.de>)
	id 1oecs9-000EQB-KM; Sat, 01 Oct 2022 15:49:41 +0200
From: Florian Weimer <fw@deneb.enyo.de>
To: Andreas Schwab <schwab@linux-m68k.org>
Cc: Sam James <sam@cmpct.info>,  Florian Weimer <fweimer@redhat.com>,
  Carlos O'Donell via Libc-alpha <libc-alpha@sourceware.org>
Subject: Re: Should we make DT_HASH dynamic section for glibc?
References: <8c6fbd40-a0c6-d84f-4e5a-10e7109ffc08@linaro.org>
	<e2918326-9329-4195-6e9a-747829f3126e@redhat.com>
	<87bkstn566.fsf@oldenburg.str.redhat.com>
	<128f4264-d3da-9b04-e567-89b4e73fe299@redhat.com>
	<20221001074055.cwwid4yxy6zdmzhn@google.com>
	<FCD1A9C7-933E-4A51-96DB-46D889A3D032@cmpct.info>
	<87edvsx7fh.fsf@linux-m68k.org>
Date: Sat, 01 Oct 2022 15:49:41 +0200
In-Reply-To: <87edvsx7fh.fsf@linux-m68k.org> (Andreas Schwab's message of
	"Sat, 01 Oct 2022 10:41:06 +0200")
Message-ID: <87czbbac22.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <libc-alpha.sourceware.org>

* Andreas Schwab:

> On Okt 01 2022, Sam James wrote:
>
>> True, but it helps those who have been on the fence and didn't
>> want to deviate from glibc upstream. It also shows that it's
>> an acceptable move to make.
>
> It's much easier to configure binutils with
> --enable-default-hash-style=both.

Changing the linker flags for the glibc build should work, too, I
think, but I haven't tested it.  These days, we just inherit what the
toolchain provides.

I any case, no patching of glibc should be needed.