This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA/RFC: Pass --cache-file=/dev/null on to subconfigures


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]