From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 623343858015; Tue, 2 Aug 2022 05:24:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 623343858015 Received: from linux-libre.fsfla.org ([209.51.188.54]:57428 helo=free.home) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIkOg-0000v0-Id; Tue, 02 Aug 2022 01:24:50 -0400 Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 2725Od6V1960636 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 2 Aug 2022 02:24:39 -0300 From: Alexandre Oliva To: Eric Gallager via Gcc-patches Cc: Andreas Schwab , Eric Gallager , Paolo Bonzini , neroden@gcc.gnu.org Subject: Re: [PATCH] configure: respect --with-build-time-tools [PR43301] Organization: Free thinker, not speaking for the GNU Project References: Errors-To: aoliva@lxoliva.fsfla.org Date: Tue, 02 Aug 2022 02:24:39 -0300 In-Reply-To: (Eric Gallager via Gcc-patches's message of "Mon, 1 Aug 2022 11:40:35 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2022 05:24:54 -0000 Hello, Eric, Thanks for looking into this. On Aug 1, 2022, Eric Gallager via Gcc-patches wrote: >> This just reassigns the value that was retrieved a couple of lines >> above from the very same variable. > Oh, ok, so I guess this isn't necessary after all? Yeah, I don't see how this patch could make any difference as to the reported problem. > In which case we can just close 43301 as INVALID then? AFAICT, with_build_time_tools is dealt with in the top level configure, setting up *_FOR_TARGET after searching for the tool names in the specified location. However, there's a potentially confusing consequence of the current code: gcc/configure looks for ./as$build_exeext in the build tree, and uses that without overwriting it if found, so if an earlier configure run created an 'as' script, a reconfigure will just use it, without creating the file again, even if it would have changed ORIGINAL_AS_FOR_TARGET in it. I suppose if the patch was tested by the original submitter on a clean build tree, so it would *appear* to have made a difference in fixing the problem, while it was actually just a no-op, and the apparent fix was a consequence of the clean build tree. So, the patch is not useful, but we may want to avoid the confusing scenario somehow. I suppose the point of not creating such a tiny script again is not to avoid unnecessary rebuilding of dependencies (I don't even see how dependencies on the script would come into play), so creating it again wouldn't hurt. However, we wish to avoid overwriting an assembler copied into the build tree for use by gcc during the build. Perhaps: -elif test -x as$build_exeext; then +elif test -x as$build_exeext \ + && { test "x$build_exeext" != "x" \ + || test "x`grep '^# Invoke as, ld or nm from the build tree' \ + as`" = "x"; }; then WDYT? -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about