This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: RFA/RFC: Pass --cache-file=/dev/null on to subconfigures
- From: Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>
- To: Charles Wilson <cygwin at cwilson dot fastmail dot fm>, Nick Clifton <nickc at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, gdb-patches at sourceware dot org, binutils at sourceware dot org
- Date: Fri, 25 Sep 2009 19:21:09 +0200
- Subject: Re: RFA/RFC: Pass --cache-file=/dev/null on to subconfigures
* 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=<foo>" top-level
> configure switch where <foo> 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 <path-to-sourceware-source>/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