solaris bootstrap failure using cc for stage1, stab.h not found...

[Jeffrey A Law]

  In message < 199811241530.KAA09922@caip.rutgers.edu >you write:
  > 	If you would please list some specific concerns, I think that
  > might help me understand why this could be dangerous. 
Consider that the generated config.cache file may be shared across many
subdirs in a single tree build -- anything built after gcc would be using
gcc's config data, but would be building with the original host compiler.

It also means that we can't do incremental builds.  ie

day 1:
make boostrap

day 2
cvs update
cd $objdir/gcc
make stage2		/* Get rid of objects we don't want anymore */
mv stage1/* .
cd ..
make bootstrap

date 3
cvs update
cd $objdir/gcc
make stage2
mv stage1/* .
cd ..
make bootstrap

I do this *all* the time.

And just a general gut feeling that it's the wrong approach.  If we've got
things which are significantly different configure-wise between stage1 and
stage2, then we've got a problem.

  > The stage1 autoconf test results are only relevant to the stage1
  > compiler.  If we can alleviate dependency concerns, I feel this is the
  > right direction.)
Right, but given that we're supposed to be compatible with the stage1 compiler
we should be able to use the same configure info.


  > http://www.cygnus.com/ml/egcs-bugs/1998-Nov/0469.html
  > 
  > none of which I really like.  Eg. revert the STABS_H->STAB_H fix, or
  > put in a solaris specific hack.
Take a step back -- why do we even care about the system provided stab.h.
 
We've got our own, as far as I know nobody disagrees on the stabs that gcc
actually uses.  Why not always use our own stab.h?  Or if that seems too
drastic, only do it for the solaris port.  That's easy and non-intrusive.




jeff