This is the mail archive of the egcs@egcs.cygnus.com mailing list for the EGCS project. See the EGCS home page for more information.

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

Re: seeing limits.h from newlib


  In message <Pine.LNX.3.96.990209072946.6411C-100000@oar3remote>you write:
  > 
  > Hi,
  > 
  > The system limits.h for RTEMS is included with newlib.  There is an
  > ordering problem on the build that requires a manual installation of this
  > file before gcc is built.  If you do not do this, then the limits.h
  > generated by gcc does not include the system's limits.h.  The Makefile.in
  > stanza in question is:
  > 
  > # Build the version of limits.h that we will install.
  > xlimits.h: glimits.h limitx.h limity.h
  >         if $(LIMITS_H_TEST) ; then \
  >           cat $(srcdir)/limitx.h $(srcdir)/glimits.h $(srcdir)/limity.h >
  > tmp-xlimits.h; \
  >         else \
  >           cat $(srcdir)/glimits.h > tmp-xlimits.h; \
  >         fi
  >         mv tmp-xlimits.h xlimits.h
  > 
  > I would like to come up with a way to avoid this ordering problem.  It
  > trips every RTEMS user who tries to build the toolset without using my
  > script.  If you simply following the standard "configure/make"
  > instructions, then it won't work because of this wart.  Here are my ideas:
  > 
So how does cygwin deal with this since I believe it has the same problem?

I'd bet it is similar to option #1 since the point of adding LIMITS_H_TEST was
to help deal with some of these kinds of issues.

jeff