The build instructions clearly say that people _must_ build in a different directory than the one containing the sources. For example, let the source directory by ~/src/gcc and the object directory be ~/src/gcc-obj. The bootstrapping sequence would be: $ cd ~/src/gcc $ cvs -z3 update $ rm -rf ~/src/gcc-obj $ mkdir ~/src/gcc-obj $ cd ~/src/gcc-obj $ ../gcc/configure $ make bootstrap $ cd gcc $ make gnatlib_and_tools $ make gnatlib-shared $ cd .. $ make install The problem is that "make bootstrap" creates a few files in the source directory. There have been instances where these files contained errors which caused subsequent bootstraps to fail, even after another "cvs update" (see PR 10740 for one example). It also means that the second step, "cvs update", is not guaranteed to produce a clean source directory from which one can make a reliable, reproducible build. I suggest that the bootstrap process be changed so as not to write any file in the source directory. Ideally, it should be possible to boostrap with the source directory on a read-only filesystem. For this, someone more knowledgeable than me should look at the bootstrap process to find all such files. So far, I have identified the following files on gcc-3_3-branch as of 2003-05-27: gcc/fastjar/fastjar.info gcc/fastjar/jar.1 gcc/fastjar/grepjar.1 gcc/gcc/cp/parse.c gcc/gcc/cp/parse.h gcc/gcc/doc/cpp.1 gcc/gcc/doc/fsf-funding.7 gcc/gcc/doc/gcc.1 gcc/gcc/doc/gcov.1 gcc/gcc/doc/gfdl.7 gcc/gcc/doc/gpl.7 gcc/gcc/f/g77.1 gcc/gcc/java/gcj.1 gcc/gcc/java/gcjh.1 gcc/gcc/java/gij.1 gcc/gcc/java/jcf-dump.1 gcc/gcc/java/jv-convert.1 gcc/gcc/java/jv-scan.1 gcc/gcc/java/parse.c gcc/gcc/java/parse-scan.c gcc/gcc/java/rmic.1 gcc/gcc/java/rmiregistry.1 gcc/gcc/objc/objc-parse.c gcc/gcc/objc/objc-parse.y gcc/gcc/c-parse.y gcc/gcc/c-parse.c gcc/gcc/gengtype-lex.c gcc/gcc/gengtype-yacc.c gcc/gcc/gengtype-yacc.h PS. The host, target and build triplets are probably not relevant, but I added them anyway. -- Ludovic Brenta.
Some of these have been semi-fixed on the mainline with the following patch, meaning that you have to change where parsedir/docobjdir is: 2003-01-10 Geoffrey Keating <geoffk@apple.com> * Makefile.in (parsedir): New variable. (docobjdir): New variable. (c-parse.o, c-parse.c, c-parse.y, gengtype-lex.o, gengtype-yacc.o, gengtype-lex.c, gengtype-yacc.c): Use parsedir. (info, cpp.info, gcc.info, gccint.info, gccinstall.info, cppinternals.info, generated-manpages, gcov.1, cpp.1, gcc.1, gfdl.7, gpl.7, fsf-funding.7, maintainer-clean, install-info, install-man): Use docobjdir. * objc/Make-lang.in (objc/objc-parse.c, objc/objc-parse.y, objc.maintainer-clean): Use parsedir. 2003-01-30 Loren James Rittle <ljrittle@acm.org> * Make-lang.in (po-generated): Find the targets in $(parsedir). Propagate change to all other rules as required. (java/parse-scan.o): Add explicit dependency on $(parsedir)/java/parse-scan.c . Here is the updated ones that need to be fixed still: gcc/fastjar/fastjar.info gcc/fastjar/jar.1 gcc/fastjar/grepjar.1 gcc/gcc/f/g77.1 gcc/gcc/java/gcj.1 gcc/gcc/java/gcjh.1 gcc/gcc/java/gij.1 gcc/gcc/java/jcf-dump.1 gcc/gcc/java/jv-convert.1 gcc/gcc/java/jv-scan.1 gcc/gcc/java/parse.c gcc/gcc/java/parse-scan.c gcc/gcc/java/rmic.1 gcc/gcc/java/rmiregistry.1 all the ones in gcc/gcc/{f,java} should be easy to fix and even the ones in fastjar are easy too. (note since gcc/gcc/cp/parse.{c,h} is no longer generated it does need fixing)
java/parse.c and java/parse-scan.c belong in ${parsedir}. The .1 and .info files from GCC belong in ${docobjdir}, I believe. Fastjar needs its own separate fix to do the same thing. I'm not sure of the current status.
I bootstrapped 3.3.1 and the bug is still there. Here are the files created in the source directory: gcc/fastjar/fastjar.info gcc/fastjar/grepjar.1 gcc/fastjar/jar.1 gcc/gcc/ada/gnat-style.info gcc/gcc/ada/gnat_rm.info gcc/gcc/ada/gnat_ug_unx.info gcc/gcc/ada/gnat_ug_vms.info gcc/gcc/ada/gnat_ug_vxw.info gcc/gcc/ada/gnat_ug_wnt.info gcc/gcc/c-parse.c gcc/gcc/c-parse.y gcc/gcc/cp/parse.c gcc/gcc/cp/parse.h gcc/gcc/doc/cpp.1 gcc/gcc/doc/cpp.info gcc/gcc/doc/cppinternals.info gcc/gcc/doc/fsf-funding.7 gcc/gcc/doc/gcc.1 gcc/gcc/doc/gcc.info gcc/gcc/doc/gccinstall.info gcc/gcc/doc/gccint.info gcc/gcc/doc/gcov.1 gcc/gcc/doc/gfdl.7 gcc/gcc/doc/gpl.7 gcc/gcc/f/g77.1 gcc/gcc/f/g77.info gcc/gcc/gengtype-lex.c gcc/gcc/gengtype-yacc.c gcc/gcc/gengtype-yacc.h gcc/gcc/java/gcj.1 gcc/gcc/java/gcj.info gcc/gcc/java/gcjh.1 gcc/gcc/java/gij.1 gcc/gcc/java/jcf-dump.1 gcc/gcc/java/jv-convert.1 gcc/gcc/java/jv-scan.1 gcc/gcc/java/parse-scan.c gcc/gcc/java/parse.c gcc/gcc/java/rmic.1 gcc/gcc/java/rmiregistry.1 gcc/gcc/objc/objc-parse.c gcc/gcc/objc/objc-parse.y gcc/libf2c/libI77/autom4te.cache P.S. I'll try with the mainline, but since a bootstrap takes 8 hours on my old machine, please bear with me :) -- Ludovic Brenta.
Created attachment 4587 [details] Differences between pristine source tree and source tree after bootstrap This is a diff made between the pristine source tree of head as of 2003-08-09 and the same source tree after a bootstrap. You can see that not only does the bootstrap create new files in the source tree, it also modifies (regenerates) gcc/libf2c/libI77/config.h.in and gcc/libf2c/libU77/config.hin.
Some one reported this to the gcc@ list: <http://gcc.gnu.org/ml/gcc/2003-09/ msg00920.html> on the mainline with a full list of the files.
I believe this request is finally fulfilled. The GCC 3.4 branch can now be built from a read-only directory. Some of the relevant patches checked in were: http://gcc.gnu.org/ml/gcc-cvs/2003-10/msg00196.html http://gcc.gnu.org/ml/gcc-cvs/2003-10/msg00666.html http://gcc.gnu.org/ml/gcc-cvs/2003-10/msg00805.html http://gcc.gnu.org/ml/gcc-cvs/2003-10/msg00817.html http://gcc.gnu.org/ml/gcc-cvs/2003-10/msg00818.html http://gcc.gnu.org/ml/gcc-cvs/2003-10/msg00826.html http://gcc.gnu.org/ml/gcc-cvs/2003-10/msg00829.html http://gcc.gnu.org/ml/gcc-cvs/2003-10/msg00845.html http://gcc.gnu.org/ml/gcc-cvs/2003-10/msg00848.html http://gcc.gnu.org/ml/gcc-cvs/2003-10/msg00862.html http://gcc.gnu.org/ml/gcc-cvs/2003-10/msg00864.html There is a new configuration option --enable-generated-files-in-srcdir which restores the old behavior for distributions of releases. This feature, though working, needs a little Makefile tweaking for proper use by the endusers without bison, flex, and makeinfo. For that, I'll file a new PR. Two files are still being produced by fastjar, of which GCC is a downstream user. I'll submit a patch for that to the upstream maintainer as well as propose a local patch for GCC. I'm closing this PR.