egcs-19980628 and limits.h

egcs-19980628 and limits.h

[Joel Sherrill]

It appears the between egcs 1.0.3 and egcs-19980628 that the definition of
SYSTEM_HEADER_DIR changed from:

SYSTEM_HEADER_DIR = $(tooldir)/include

to

SYSTEM_HEADER_DIR = $(tooldir)/sys-include

This has broken RTEMS installation of limits.h.  RTEMS' system limits.h is
in newlib and although there are build ordering problems, it does end up
in $(tooldir)/include which trips the "limits.h exists" path.

Any ideas on how to address this other than to "pre-install" 
$(tooldir)/sys-include/limits.h before beginning a build?  Doing this
feels like a kludge but works.  To prevent having to add sys-include to
the include path, I would still let the regular newlib install process put
limits.h in the $(tooldiir)/include directory. 

Comments appreciated.  My impression is that the new scheme is OK for
Canadians but may require some presetup for embedded crosses.  It would be
cool if newlib new what to do to get its header files in place before gcc
ran.

--joel 

Re: egcs-19980628 and limits.h

[Jeffrey A Law]

  In message < Pine.BSF.3.96.980714092137.10553A-100000@vespucci.advicom.net >you write:
  > 
  > It appears the between egcs 1.0.3 and egcs-19980628 that the definition of
  > SYSTEM_HEADER_DIR changed from:
  > 
  > SYSTEM_HEADER_DIR = $(tooldir)/include
  > 
  > to
  > 
  > SYSTEM_HEADER_DIR = $(tooldir)/sys-include
Right.  This was done to help crosses.


SYSTEM_HEADER_DIR is meant for stuff provided externally that may need
fixincludes, fixproto, etc etc.  It is also the location where we are
supposed to find limits.h, float.h,  which we may want to wrap.


  > This has broken RTEMS installation of limits.h.  RTEMS' system limits.h is
  > in newlib and although there are build ordering problems, it does end up
  > in $(tooldir)/include which trips the "limits.h exists" path.
I don't follow this exactly.  Maybe you mean "sys-include" above?

  > Any ideas on how to address this other than to "pre-install" 
  > $(tooldir)/sys-include/limits.h before beginning a build?  Doing this
  > feels like a kludge but works.  To prevent having to add sys-include to
  > the include path, I would still let the regular newlib install process put
  > limits.h in the $(tooldiir)/include directory. 
So, do you want LIMITS_H_TEST to pass or fail?

If it fails, gcc will provide its own limits.h.

If it succeeds, then gcc will wrap it in between limitx.h and limity.h

Either way you should be able to override LIMITS_H_TEST in your t-*
file.  See config/i386/t-{cygwin32,next} and config/rs6000/t-beos.

jeff