Re: cross-builds failing

[Jeffrey A Law <law at cygnus dot com>]

  In message <199810080903.KAA17244@sun52.NIS.cambridge>you write:
  > Nope, at least, not as of 6pm BST yesterday.  I think it is the change to 
  > the build rule for cccp.o (which puts libunsubdir in for all the include 
  > search paths).  Here is the results of running the command with -v
Ah.  Dumb me.


[ ... ]
  > /home/rearnsha/gnu/egcs/install/SunOS5/lib/gcc-lib/arm-semi-aout/egcs-2.92.
  > 13/../../../../arm-semi-aout/include
  > /home/rearnsha/gnu/egcs/install/SunOS5/lib/gcc-lib/arm-semi-aout/egcs-2.92.
  > 13/../../../../arm-semi-aout/sys-include
  > /home/rearnsha/gnu/egcs/install/SunOS5/lib/gcc-lib/arm-semi-aout/egcs-2.92.
  > 13/include
  > /home/rearnsha/gnu/egcs/install/SunOS5/lib/gcc-lib/arm-semi-aout/egcs-2.92.
  > 13/../../../../include/g++
  > 
  > 
  > Actually, I think this is all somewhat irrelevant, since the compiler 
  > shouldn't be looking in the install area when newlib is in the source 
  > tree.  It should really be getting the headers from 
  > ${srcdir}/...../newlib/....
No, it shouldn't be looking in the newlib sources (or more correctly, it
does not look there and never has looked there).  Sorry, I should have caught
this earlier.

libgcc2.c instead is supposed to avoid including stdio.h and friends when
building with newlib.

Either something is including stdio and unistd unconditionally, or inhibit_libc
is not being defined.

The toplevel configure.in should be finding your newlib source directory and
turning on --with-newlib by default.  That in turn causes gcc/Makefile to
define inhibit_libc which is supposed to prevent the problem include files
from being included.

I think this problem is separate from the unlibsubdir problems.

jeff