Path: utzoo!telly!ddsw1!mcdchg!rutgers!mit-eddie!bloom-beacon!apple!vsi1!daver!cheers!exodus
From: exodus@cheers.uucp (Greg Onufer)
Newsgroups: gnu.gcc.bug
Subject: Re: problem with making gcc on Sun4/SunOs 4.0
Message-ID: <210@cheers.uucp>
Date: 11 Nov 88 08:56:23 GMT
References: <468@dmk3b1.UUCP>
Distribution: gnu
Organization: Cheers Bar & Grill, Boston
Lines: 32

From article <468@dmk3b1.UUCP>, by dmk@dmk3b1.UUCP (David Keaton):
> In article <8811091516.AA14509@sunbar.mc.duke.edu> ndd@SUNBAR.MC.DUKE.EDU (Ned Danieley) writes:
> )make CC=stage1/gcc CFLAGS="-g -O -Bstage1/"
> )stage1/gcc -g -O -Bstage1/ -sun4 -c  toplev.c
> )stage1/gcc: Program cc1 got fatal signal 6.
> )*** Error code 1
> )make: Fatal error: Command failed for target `toplev.o'
> )I appear to have correctly followed the installation instructions;
> )is this a bug?
> Yes, it's a bug, but the bug is Sun's.  They have changed the meaning
> of the -B flag to cc.  Their equivalent of "-Bstage1/" would be
> "-Qpath stage1".

No bug that I see...  David is not using Sun's C compiler.  -Bstage1/
is a flag for _gcc_ to tell it where to look.  Sun's CC should not be
called anywhere at this point (using the first generation gcc to compile
the second generation).  It looks like David installed everything
correctly so the bug may very well be in gcc.  I haven't gotten a
a trustable gcc running on the Sun Roadrunner for that matter.  Gcc-1.28
works fairly well, but only if it doesn't use __builtin_alloca (ie.  It
compiles itself with stage2/gcc with no differences in the object
files other than in the damned COFF headers-- why did Sun have to do
that to us?  Is a binary standard _that_ important to them?).  When
using __builtin_alloca, stage2/gcc cannot compile itself (or anything
with Optimization turned on).

Any clues?

--greg
-- 
Greg Onufer .. University of the Pacific .. Focus Semiconductor
.. exodus@cheers.uucp .. sun!daver!cheers!exodus .. 415-965-0604