Richard Kenner wrote:
From the user point of view it is a bad bug that you cannot bootstrap
a 64-bit compiler starting from a 32-bit one (because stage2 does not
find a 64-bit libiberty to use).
To me, "bootstrap" means that all three compilers are identical in
configuration, so I don't follow your example.
In this case, the target is the same, but the machine is able to execute
objects for more than one configuration. build, host, and target all
are for example powerpc64-linux, but the host compiler defaults to
creating 32-bit objects and the bootstrapped compiler will default to
creating 64-bit objects.
So the stage1 compiler is built as a 32-bit object, from the second
stage on they're built as 64-bit objects.
Since that's what I (and others, from the sound of it), need to do all the
time, it sounds like we'll keep using --disable-bootstrap forever.
Why can't you execute make bootstrap in the toplevel?
What I do is working on a fix in the stage1 directory, and then doing
(depending on the kind of bug and fix) "make unstage1; make restrap" or
"make bubblestrap". With the new method they become respectively "cd ..
&& make restrap", and "cd .. && make". I re-bootstrap only when I
expect things to go smoothly, at the *end* of the debugging.
Are you doing things differently? (This is not kidding; maybe there's
some fundamental misunderstanding).
Paolo
