From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hamza.pair.com (hamza.pair.com [209.68.5.143]) by sourceware.org (Postfix) with ESMTPS id 4A0763858D32 for ; Sun, 22 Jan 2023 01:45:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4A0763858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=pfeifer.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=pfeifer.com Received: from hamza.pair.com (localhost [127.0.0.1]) by hamza.pair.com (Postfix) with ESMTP id 74F2D33E90; Sat, 21 Jan 2023 20:45:56 -0500 (EST) Received: from naga.localdomain (188-23-1-149.adsl.highway.telekom.at [188.23.1.149]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hamza.pair.com (Postfix) with ESMTPSA id 7246833E8D; Sat, 21 Jan 2023 20:45:55 -0500 (EST) Date: Sun, 22 Jan 2023 02:45:53 +0100 (CET) From: Gerald Pfeifer To: Tobias Burnus cc: gcc-patches , Tom de Vries , Thomas Schwinge , =?ISO-8859-15?Q?Martin_Li=A8ka?= , Matthias Klose Subject: Re: [Patch] install.texi: Bump newlib version for nvptx + gcn In-Reply-To: Message-ID: <13b420c5-f19c-016c-3fbb-b3df6532962b@pfeifer.com> References: <11d635d0-9798-5344-934b-969cb01974ba@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; CHARSET=US-ASCII X-Scanned-By: mailmunge 3.10 on 209.68.5.143 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sat, 21 Jan 2023, Tobias Burnus wrote: > On the technical side, the newer newlib version is not yet required. But > it looks as if it soon makes a lot of sense to have it: : > As nvptx/amdgcn is (mostly) about offloading code, newlib is compiled > usually alongside GCC (e.g. in SUSE, Debian/Ubuntu, ...); additionally, > there is static linking such that mixing old vs. new libraries is less > likely. Hence, requiring the newest version of newlib together with the > newest compiler shouldn't be a problem in my opinion. That sounds like a convincing argument. >> And, this predates your patch, in one instance we refer to Newlib >> (upper case9, in the other to newlib (lower case). Would it make >> sense to converge to one? > Maybe, but the question is what to use? The project's webpage has on the > first page: "patch submissions to Newlib" and "automate the testing of > newlib". I also dug into the newlib web page and other sources and - while my personal preference slightly leans towards Newlib - believe newlib is more established overall. For the web pages, it's clearer than for our *.texi ones you dug into: ~/src/wwwdocs/htdocs> grep -r newlib . | wc -l 15 ~/src/wwwdocs/htdocs> grep -r Newlib . | wc -l 3 > Thoughts? Let's go for newlib (lowercase) I'd say; if you agree I can take care of wwwdocs Cheers, Gerald