From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 22927385BF81 for ; Wed, 23 Feb 2022 11:33:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 22927385BF81 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=foss.arm.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=foss.arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B32BE106F; Wed, 23 Feb 2022 03:33:02 -0800 (PST) Received: from [10.57.15.132] (unknown [10.57.15.132]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 31CB93F70D; Wed, 23 Feb 2022 03:33:02 -0800 (PST) Message-ID: <5316b8e2-fd3e-0ad3-82f9-255cabd0ca1b@foss.arm.com> Date: Wed, 23 Feb 2022 11:33:01 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: newlib not building (needs aclocal) Content-Language: en-GB To: newlib@sourceware.org, Brian Inglis References: <6e6ec1c8-70b3-5cc2-3b06-60f516a44ed0@foss.arm.com> <367ed8f2-e428-aacb-a4f9-82119d6408e4@SystematicSw.ab.ca> From: Richard Earnshaw In-Reply-To: <367ed8f2-e428-aacb-a4f9-82119d6408e4@SystematicSw.ab.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3489.6 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2022 11:33:04 -0000 On 23/02/2022 06:01, Brian Inglis wrote: > On 2022-02-22 04:57, Richard Earnshaw wrote: > >> I think something you've changed is forcing the newlib build to now >> need a local installation of automake.  This wasn't needed before >> unless you were updating the makefiles locally. >> >> CDPATH="${ZSH_VERSION+.}:" && cd [...]/libgloss && /bin/bash >> [...]/missing aclocal-1.15 -I . -I .. -I ../config >> [...]/missing: line 81: aclocal-1.15: command not found >> WARNING: 'aclocal-1.15' is missing on your system. >>           You should only need it if you modified 'acinclude.m4' or >>           'configure.ac' or m4 files included by 'configure.ac'. >> >> Did you leave something out of a commit somewhere?  If not, how can >> this be fixed so that we don't need automake during normal builds from >> the repo? >> >> R. >> >> PS While I appreciate what you're trying to do here, the timing >> couldn't be worse given that we're trying to stabilize a GCC release >> and all my builds are breaking at present. > > If you need stability, shouldn't you freeze your newlib pull at year end > 4.2.0 20211231 484d2eb snapshot, earlier about 2021-09-06 522cdab, just > before Mike started his optimization and cleanup marathon, or maybe add > an arm-gcc-dev(-11?) tag at some point in there? Well for testing gcc-12 a freeze for gcc-11 is not very helpful. Newlib doesn't have release branches (not really sure why not, especially when there are potential security issues to deal with), and while I could freeze against specific tags, that would mean I never test tip-of-tree newlib. Fortunately, over the years newlib has been very stable and it has been rare for there to be much breakage (at least, breakage that prevents building at all). > > Do you think perhaps devs doing extended or extensive work should create > their own newlib, topic, or remote tracking branches (as Cygwin devs do > for major work - see summary page heads or git ls-remote --heads > --sort=-creatordate | head) and commit work there, perhaps merging back > to master at intermediate points, or even not until complete? > There might be a case for this, particularly for disruptive changes. It's a matter of balance, given the size of the newlib project. As I said before, I fully support modernizing newlib's make structure, it's just a little unfortunate that it's being done during the run-up to gcc-12. R.