GCC 4.2.1 : bootstrap fails at stage 2. compiler produces wrong binary for wrong processor

Ian Lance Taylor iant@google.com
Fri Jul 27 17:01:00 GMT 2007


"Dennis Clarke" <dclarke@blastwave.org> writes:

> > "Dennis Clarke" <dclarke@blastwave.org> writes:
> >
> >> SUMMARY : the stage 2 compiler produces the wrong binary type for this
> >> machine
> >
> > This question is appropriate for the gcc-help@gcc.gnu.org mailing list
> > rather than the gcc@gcc.gnu.org list.  Please take any followups to
> > gcc-help.  Thanks.
> 
> I was not aware that this list was not a general gcc mail list.

The list gcc@gcc.gnu.org is for people developing gcc.  The list
gcc-help@gcc.gnu.org is for people using gcc.  The list descriptions
may be found at http://gcc.gnu.org/lists.html.  I again request that
you take any followups to gcc-help.  Thanks.


> >> In either case I think that the --host needs to be specified as well as
> >> perhaps --with-cpu=foo or something like that in the ./configure line.
> >
> > It does seem from your description that you need to set the host
> > explicitly.  That is not documented because it is rarely necessary.
> 
> Hardly a valid point.  The terms "not documented" is just not a very
> open source way of doing things.  Oh well ... I guess I have to hunt
> for that.

We use configure scripts generated by autoconf.  We do not document
every possible option used by such scripts.  We only document the ones
which are specific to gcc and the ones which are likely to be useful
for people using gcc.  For the full documentation of generic autoconf
options, please see
    http://www.gnu.org/software/autoconf/manual/autoconf-2.57/autoconf.html


> Well the idea here is that any old generation sparc machine ( sun4m ) will
> produce binaries that run on everything all the way up to the new Niagara
> and Sun UltraSparc IV without issue.  Any difference in performance is a
> secondary and minor consideration that boils down to clock speed anyways.
> 
> At the moment GCC 4.2.1 seems to be tied to the UltraSparc processor and
> thus the older sun4m and 32-bit Sparc machines are being ignored.  They are
> still out there and still running in various places.  The real issue
> *should* be that I can build GCC for a basic Sparc target if I want.

If I understand correctly, then your best bet here may be to not worry
about --build, but to instead use the --with-cpu option when you run
configure (e.g., --with-cpu=v7).  It appears that for Solaris 2.8 gcc
will assume --with-cpu=sparcv9 if you don't explicitly use --with-cpu
itself.

Ian



More information about the Gcc mailing list