On 1/16/06, Richard Kenner <[EMAIL PROTECTED]> 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.
