libiberty patch - configure/makefile for cygwin

[Jeffrey A Law]

  In message < 200006140324.XAA04289@envy.delorie.com >you write:
  > 
  > > Shouldn't the EXTRA_INCs stuff already be handled by the definition
  > > of CC_FOR_TARGET in the toplevel Makefile for target builds?  Or am
  > > I missing something?
  > 
  > You'd think so, but it doesn't when you're not also building gcc in
  > the same build (CC_FOR_TARGET only includes the extra incs when
  > .../gcc/xgcc exists).  The problems I've seen are from building just
  > the cygwin module under cygwin.
Ah.  That's the key point I was missing.  I didn't even know cygwin could
be built independently of GCC, but then again I can't think of a fundamental
reason why that wouldn't work either.


  > I'm willing to add the includes to the second set of cases in that
  > snippet, but I don't know what negative effects that might have on
  > other builds.  Plus, it prevents you from just typing "make" in the
  > target libiberty directory and expecting it to work.
Yea.  But that's always been on the iffy side anyway.  I'm actually hoping
some of Alexandre's recent work cleans this kind of thing up a little.


  > I'm also not sure that blindly including from newlib just because it's
  > there is always the right thing to do; it really should reflect the
  > --with-newlib option.
Agreed.

  > > The bits for removing strsignal, are probably OK to go ahead and check
  > > in.
  > 
  > I don't have checkin privs for gcc.
We fixed that, right :-)



So ultimately, after Alexandre's recent hackery, what is the right thing to
do to get cygwin builds working again independently of gcc?

jeff