This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: egcs-19980628 and limits.h



  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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]