From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14813 invoked by alias); 25 Sep 2009 17:21:21 -0000 Received: (qmail 14792 invoked by uid 22791); 25 Sep 2009 17:21:19 -0000 X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_00,FAKE_REPLY_C,J_CHICKENPOX_92,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.gmx.net (HELO mail.gmx.net) (213.165.64.20) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Fri, 25 Sep 2009 17:21:14 +0000 Received: (qmail invoked by alias); 25 Sep 2009 17:21:11 -0000 Received: from xdsl-87-78-64-82.netcologne.de (EHLO localhost.localdomain) [87.78.64.82] by mail.gmx.net (mp023) with SMTP; 25 Sep 2009 19:21:11 +0200 Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1MrETm-0000Uk-8N; Fri, 25 Sep 2009 19:21:10 +0200 Date: Fri, 25 Sep 2009 17:21:00 -0000 From: Ralf Wildenhues To: Charles Wilson , Nick Clifton Cc: gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org, binutils@sourceware.org Subject: Re: RFA/RFC: Pass --cache-file=/dev/null on to subconfigures Message-ID: <20090925172108.GA1808@gmx.de> Mail-Followup-To: Ralf Wildenhues , Charles Wilson , Nick Clifton , gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org, binutils@sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ABCD89E.6040406@redhat.com> <4ABCD858.3030400@cwilson.fastmail.fm> User-Agent: Mutt/1.5.20 (2009-08-09) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00810.txt.bz2 * Nick Clifton wrote on Fri, Sep 25, 2009 at 04:50:06PM CEST: > >> Any comments or reasons why the patch should not be applied ? > > > >Yes. Unless you have actively changed any precious variables, they > >should not be inconsistent and the cache should not be invalidated. > > Ok, first of all though, do you agree that it should be possible to > build a toolchain without using config caches ? Ie should a > "--cache-file=/dev/null" specified at the top level be passed on to > the configure scripts in sub-directories ? Please do commit it, since I guess it is necessary in practice. However, this necessity is always a sign of a bug in the GCC/src build system. > Also, as an aside, what about a "--config-file=" top-level > configure switch where is a non-absolute filename. Eg: > > --config-file=foo.config.cache > > Should a switch like this be allowed to change the name of the > config cache files used in the sub-directories ? Currently this > will not work, and my patch would not fix this, but I was wondering > if it was expected to work. Well, with upstream Autoconf, you only ever have one cache file anyway, so it works there. GCC/src could easily let such a switch cause the use of different cache file names in the sub-directories. I'm not sure what the benefit would be, though. > >Can you please provide me with a recipe to reproduce this > > OK, here is what works for me. Thanks. I will investigate it. A couple of notes: [...] > % make all-target-newlib > % touch /newlib/configure > % make all-target-newlib > > Result: > > configure: error: changes in the environment can compromise the build > configure: error: run `make distclean' and/or `rm ./config.cache' > and start over > make[1]: *** [Makefile] Error 1 There should be more information in the error message, namely the variable(s) that changed and how they changed. This information can be helpful to find the bug. > Note that the configure script at the top level of the newlib source > directory was built with autoconf v2.59. That is not a problem *per se*: a couple of caching bugs were fixed in 2.60, and 2.62, respectively, but the toplevel config/override.m4 file has overrides for these fixes that *should* work for any released Autoconf between 2.59 and current. The only crucial bit is that override.m4 is used for creating newlib/configure (and all other configure scripts, for that matter). If aclocal is used, then adding '-I ../config' or similar to its flags (ACLOCAL_AMFLAGS) should be sufficient, otherwise adding sinclude([../config/override.m4]) early in configure.ac (before AC_INIT) works. The current newlib uses confsubdir.m4 which fixes one of the problems, but not the other. * Charles Wilson wrote on Fri, Sep 25, 2009 at 04:48:56PM CEST: > I've seen it happen -- building gdb/insight which is part of the src > tree if not gcc specfically -- when a precious variable contained a > leading space. This is probably one of the bugs fixed by override.m4, and the insight part is one that the autotools update hasn't touched. Cheers, Ralf