RFA/RFC: Pass --cache-file=/dev/null on to subconfigures
Nick Clifton
nickc@redhat.com
Fri Sep 25 15:09:00 GMT 2009
Hi Ralf,
>> 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 ?
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.
> Can you please provide me with a recipe to reproduce this
OK, here is what works for me. Using the latest gcc and sourceware
mainline sources, with symlinks from the gcc source directory to the
sourceware source directory, on a Fedora 11 x86 host, in an empty
directory, run the following commands:
% <path-to-top-level-gcc-sources>/configure \
--quiet \
--target=arm-eabi \
--enable-languages=c
[The configure options are not essential, but they do make it faster
to reproduce the problem. I suspect that you need to choose a target
that uses multilibs].
% 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
Note that the configure script at the top level of the newlib source
directory was built with autoconf v2.59. This is doubtless part of the
problem. But the issue is that if the gcc sources are part of an
integrated source tree where some of the configure files have not been
created with the latest version of autoconf (2.64 ?) then rebuilds of
the toolchain can fail.
Requiring that all configure files be updated to the latest autoconf
version might be the technically correct way to solve the problem, but
is not really a very practical solution. Allowing toolchains to be
configured without config caches is a workaround, but one that is much
simpler to adopt.
Cheers
Nick
More information about the Gcc-patches
mailing list