From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS,URIBL_BLACK shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 06CE91F4C1 for ; Mon, 28 Nov 2022 15:37:26 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="Zfx/GlIQ"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2853C38518AE for ; Mon, 28 Nov 2022 15:37:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2853C38518AE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1669649843; bh=VZsld7ndrd/IlWN7bTldyiJFv//ckSSA8E11jziFz/E=; h=To:Cc:Subject:References:Date:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=Zfx/GlIQoJrOsQkotoYJZLZpK2vz/CKOYnaEjphJU2RTQ2qc6Le9oJL9YUzfR2Sz8 mF+H+Btj2lK0sRMoU/sG9cApbRoiK4HALrjVPdfnisNVu/egDMNQ6a/J4PcvZKOlow hfWdXodeyzkMMe7S2bjynyjBOqTZ/XxuW2gzSFhA= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 3D99738532F9 for ; Mon, 28 Nov 2022 15:37:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3D99738532F9 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozgBr-0002cf-GT; Mon, 28 Nov 2022 10:37:03 -0500 Received: from [193.50.110.137] (helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozgBq-0007li-Qp; Mon, 28 Nov 2022 10:37:03 -0500 To: Vineet Gupta Cc: libc-alpha@sourceware.org, Carlos O'Donell , Fangrui Song , nelson Chu , palmer@rivosinc.com, gnu-toolchain@rivosinc.com Subject: Re: [PATCH] Revert "Correctly determine libc.so 'OUTPUT_FORMAT' when cross-compiling." References: <20221123025932.473655-1-vineetg@rivosinc.com> <87lenx9315.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Octidi 8 Frimaire an 231 de la =?utf-8?Q?R=C3=A9volu?= =?utf-8?Q?tion=2C?= jour du Miel X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Mon, 28 Nov 2022 16:37:00 +0100 In-Reply-To: (Vineet Gupta's message of "Sun, 27 Nov 2022 18:24:47 -0800") Message-ID: <875yezccpv.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: =?utf-8?q?Ludovic_Court=C3=A8s_via_Libc-alpha?= Reply-To: =?utf-8?Q?Ludovic_Court=C3=A8s?= Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" Hi, Vineet Gupta skribis: > On 11/26/22 06:57, Ludovic Court=C3=A8s wrote: >> Hi, >> >> Vineet Gupta skribis: [...] >>> riscv glibc multilib builds lack riscv32 prefix binaries. They have a >>> single set of "riscv64" prefixed binaries supporting both 32 and 64-bit >>> abis: ilp32/ilp32d/lp64/lp64d using -march/-mabi. [...] > The issue is this patch makes an assumption that a triplet prefixed > cross binary exists, which may not always happen in multilib setups. Sorry, I had overlooked that. I trust your judgment. It does seem that we=E2=80=99ll have either one issue or the other though. Downstream we can adjust either way, so that=E2=80=99s okay. Thanks, Ludo=E2=80=99.