Re: Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)

[Richard Guenther <richard dot guenther at gmail dot com>]

On 1/16/06, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
>     This is the default setup you will run into on any ppc64-linux host.  It's
>     definitely annoying that you have to workaround this in weird ways.
>
> I don't follow.  Why would you ever want to build the stage1 compiler as
> a cross-compiler and then do a "bootstrap"?  I don't consider starting
> the process with a native compiler as a "workaround", but as proper
> practice.  Otherwise, as I said, you have the wierd situation where the stage1
> compiler is a cross-compiler but the stage2 and stage3 compilers are native,
> which gets seriously in the way of debugging a bootstrap problem.

On a ppc64 system, while the kernel is 64bit, the userland usually defaults to
all 32bit, so the system compiler is configured to build 32bit
binaries by default
(i.e. using -m32), while HOST_WIDE_INT is still 64bits and you can
generate 64bit
binaries using -m64.  So a naiive ./configure && make will configure for
host == target == powerpc64 but still (wrongly so in your opinion?) build stage1
as 32bit binaries (but defaulting to -m64 code generation now), and
the following
stages will now become 64bit.

This currently (without a patch I posted) breaks, because we build
libiberty just
once, as a 32bit library for stage1, but that fails to link stage2 and
on because a
64bit libiberty is missing.

So call it a failure of either configure not detecting we're lying
about the ppc64 host
or a bug of the recommended system compiler setup on ppc64.

Richard.